« Page 16 of 18 »

  1. Amazon has released the latest version of the Elastic Compute Cloud (EC2) API: 2008-02-01.

    This release includes a number of new features, two of which are very interesting: Elastic IP Addresses and User Selectable Kernels.

    Elastic IP Addresses

    Elastic IP Addresses allow you to allocate static IP addresses to your AWS account, and programmatically associate these addresses with your EC2 instances. This feature should make it feasible to map DNS names directly to EC2 instances without using dynamic DNS naming services. If your instance dies or if you plan to terminate it, you can simply start another instance and reassign the elastic IP address to it.

    Reserving (allocating) yourself an IP address costs 1¢ per hour that the address is not associated with a running instance, and there is no charge for addresses that are associated with an instance. By default there is a limit of 5 IP addresses per account, but this limit can be increased upon request.

    User Selectable Kernels

    User Selectable Kernels allow you to user alternative Linux kernels to the default one provided by Amazon. To make this possible, the EC2 environment will contain two new kinds of images in addition to the Amazon Machine Images (AMIs) we are familiar with: Amazon Kernel Images (AKIs) and Amazon RAM disk Images (ARIs). The new API and bundling tools allow you to mix-and-match machine images with kernel and RAM disk images, though you have to be careful doing this as not all the images will work well together.

    Note that you cannot create and load your own kernels. Instead, you must choose from a set of kernels made available by Amazon and “selected vendors”. Hopefully a future API version will make it possible for anyone to create their own customized kernel images.

    Availability Zones

    In addition to these two features, the new API also includes support for Availability Zones that allow you to specify the location(s) where your EC2 instances will run. Eventually the list of locations may include multiple regions (ie. countries or geographical areas) but currently all EC2 data centers are located in the United States. There are a number of zones or locations within the US region, for example: us-east-1a, us-east-1b, us-east-1c. This feature will help to distribute, or concentrate, your EC2 instances depending on the requirements of your application.

    There are comments.

  2. I am pleased to announce that my book Programming Amazon Web Services: S3, EC2, SQS, FPS and SimpleDB is now officially published and should soon be available from booksellers. It will hopefully prove to be a valuable resource for people who are building applications on top of Amazon's infrastructure services, or who are considering doing so.

    You can find out more about the book or order a copy from the O'Reilly catalog or Amazon.com (affiliate link).

    The book contains a large number of code examples written in Ruby, including example client implementations for all five infrastructure services. This code, as well as corresponding implementations written in Java and Python, will shortly be available for download from the O'Reilly catalog page. There is also a forum where you can discuss the book or ask questions.

    There are comments.

  3. Amazon AWS developers are planning to add a new "copy" feature to the Simple Storage Service (S3) API that will make it possible to copy your data objects to a new location in the service. This feature could be used to rename objects you have already stored (copy to a new name), to relocate them to a different bucket, or even to relocate them between S3 locations (US to EU, and vice versa).

    At present, if you want to do any of these things you must upload all the data from scratch and you cannot take advantage of the fact it is already present in the service.

    The feature proposal document is here:
    http://doc.s3.amazonaws.com/proposals/copy.html

    And there is a forum discussion topic where you can ask further questions and provide feedback on the proposal:

    http://developer.amazonwebservices.com/connect/thread.jspa?threadID=20409

    http://developer.amazonwebservices.com/connect/thread.jspa?threadID=20409&tstart=0
    

    There are comments.

  4. While writing a proof-of-concept Ruby on Rails application (Ruby 1.8.6, Rails 2.0.2) I was stumped by an intermittent problem where long-lived processes would fail with the error message:

    <ArgumentError: A copy of TransactionController has been removed from the module tree but is still active!>
    

    Admittedly, I do some potentially dodgy things in this application. I initiate a transaction in a TransactionController but cannot tell in advance how long it will be until the transaction is finished – it may succeed immediately or it may take several seconds. To keep the web site visitor from waiting, the controller returns a result web page immediately and spawns a Thread to continue processing the transaction in the background. This thread updates one or more model objects as the transaction's status changes, and these model objects are derived from a plugin class.

    The thread worked well in most cases, but it would fail when the transaction took longer than a few seconds. The error seemed to be triggered when the code created a new model object.

    The workaround I found for this issue was to enable class caching in my development environment. This caching is enabled by default in the production environment but not in development. To enable it, I edited the config.cache_classes property in the config/environments/development.rb configuration file like so:

    config.cache_classes = true
    

    This setting disables class reloading in the development environment, which means that you must restart the server before code changes will be applied. This is a pain when you are developing an application, so I only set this option to true when it is necessary to test slow transactions.

    I assume this issue is caused by Rails unloading the plugin's model classes when it does a sweep looking for changed code files. It is a shame this occurs even when no code changes have been made. And despite the fact the error message names the controller class, in my testing the error was only ever triggered by code that operated on model objects. If I removed references to the models, the thread would do its job no matter how long the transaction took.

    I am no Rails expert so there is a good chance I am doing something drastically wrong. I did spend some time looking for a better way to spawn background thread tasks from a controller action, but the suggestions I found involved running separate processes on the server machine and communicating with them via sockets or shared database tables – an arrangement that isn't much less hacky than what I'm currently doing.

    If you know of a saner way of doing this, please let me know in the comments.

    There are comments.

  5. Gmail has a nasty bug (or quirk) that I have only just discovered. It explains why I sometimes have trouble searching for specific emails in my archive. To use Gmail effectively you will need to know about this bug, and how to avoid it.

    Background

    In Gmail, messages are automatically grouped together into a conversation based on the subject line of the emails. When you reply to a message, or receive a new message with the same subject line, it is added to the conversation.

    You can apply labels to a conversation to help organise your archive, and to make it easier to search. For example, I label any JetS3t-related emails I receive with the "jets3t" label. Once I have done this, any responses I send or replies I receive can be found by searching for conversations with the "jets3t" label.

    Label Granularity – Conversation or Message?

    I had assumed that Gmail applies labels at the conversation level. The UI presentation implies that this is the case, because the label names are displayed at the top of the conversation and it is not possible to apply labels to individual messages. However, it seems that this is not the way Gmail works.

    Instead of a label being applied to a whole conversation, it looks like the label is only applied to the messages in a conversation at the time you add the label. Any messages that are added to the conversation later on will not inherit this label.

    Misleading search results

    I have found several examples where label-based searches that seem straight-forward will not return the results you expect. Two particularly nasty cases where your search results may be misleading are when you apply a star to an individual message in a conversation, or if there is an attachment later on in a conversation. Let's look at a real example of the latter case.

    I received a JetS3t-related email with a feature request. I applied the "jets3t" label to this conversation and then replied. After a couple of emails back-and-forth, I sent a message with a PDF file attachment to the person who requested the feature.

    Now, let's say I want to find all the JetS3t-related conversations where I have sent or received an attachment. The obvious search to perform is:

    label:jets3t has:attachment
    

    However, this does not include my email in the results. I know it should be there, so what gives? I try listing all the messages that have the "jets3t" label:

    label:jets3t
    

    This search returns a list of conversations that includes the one in which I sent the attachment, along with hundreds of others. I can also find this particular conversation by searching for all of the messages in my archive that have attachments:

    has:attachment
    

    So why doesn't the joint search (label:jets3t has:attachment) find this conversation? Because although the message I sent is inside a "jets3t" conversation, the message itself is not associated with this label. The message is only loosely associated with the "jets3t" label because it happens to belong to a conversation in which other messages have this label.

    To make this particular search perform properly, I forced Gmail to associate every message in the conversation with the "jets3t" label by re-applying the label to the conversation. After doing this, the joint search finally returned my email in its results.

    Beware

    This Gmail quirk makes it difficult to use label-based searches with confidence. Unless you perform the tedious work-around of manually re-applying your labels every time a new message is added to a conversation, you cannot be sure that searches against a label name and another criteria will return all the results you would expect.

    This bug will affect any message-specific search criteria. In addition to the starred message and attachment cases I have mentioned, it will also affect searches against specific recipients or senders, and searches against particular dates. You should also be aware that the date shown next to a conversation in a label view can be misleading, as it shows the date of the last labelled message rather than the date of the last message in the conversation.

    I have found a couple of mentions of this issue, one going back a long time, so I can only assume that this bizarre and opaque behaviour is the way it is meant to be?

    There are comments.

« Page 16 of 18 »