timing is everything

one of the best things about being a web developer right now is the huge amount of resources available to help developers like me accomplish what it is we want to do. the amazon web services offerings are especially noteworthy. for the first time, infrastructural elements such as storage and processing power are now available as a service, and acquired on demand. this means that developers can leverage an essentially infinite pool of resources for absolutely zero fixed cost, but only pay for what is actually used. for many, bootstrapping an application is now a complete reality. at work recently, i’ve been building an application with a storage model based on amazon’s s3 (simple storage service). it’s been a wonderful experience so far, and everything’s been working great up until a few days ago. i just realized that this post is about to abruptly shift from a nice general overview to a incredibly specific level of detail, so to spare those less technical *cough (nerdy)* readers, the slightly amusing story and s3 troubleshooting tip is after the break.

you actually bought the “slightly amusing story” line? so, i’ve had an s3 implementation up and running fine with no issues for about 2 months now… i’m using their java package, and i’ve written a simple file system interface on top of that. then one day, in the midst of making a handful of other unrelated changes to the application, i realized that the s3 piece ceased to work. no files were being transferred either up to or down from the cloud, but i could have sworn i didn’t mess with any of that code! to make things even weirder, i was able to access the files from both my local development machine and my home development machine, running the exact same code. so, when the going gets tough… i start working on something else. well, today i had no choice but to get back to it and figure out what was going on. after spending about an hour debugging, and getting at the nitty gritty of the http connection performing the REST interaction, i finally figured it out. the clock on the linux server was about 10 minutes fast. i’m not sure exactly why that caused a problem, but i think the requests are signed and the timestamp wasn’t playing well with amazon’s official time. i’m also not sure how the clock went from being ‘close enough’ to ‘unacceptable,’ but that’s another story entirely. just wanted to throw this out there in case some desperate developer is searching for answers…

and now for the anecdote – i was just about at my wit’s end, and on the edge of giving up until another day… but as the next song came onto my ipod, at 5 minutes and 30 seconds long, i told myself i’d figure it out by the end of the song. i compared requests from two machines side by side, and noticed the timestamp difference, re-set the clock using the following code
date [MMDDhhmmYYYY]
(i also reset the hwclock to avoid this problem next time i reboot)
and with six seconds left in the song… that machine had its first successful discussion with amazon in a week!

just goes to show the power of positive thinking. what was the song, you ask? ‘atlanta’ by canibus. inspiring, i know…

3 Responses to “timing is everything”

  1. Kin Lane Says:

    Yeah that was pretty geeky. Could you get back to the normal banter please?

  2. aboone.com » Blog Archive » Managing Multi-Node EC2 Deployments with SVN, Ant and bash Says:

    [...] somewhat familiar with Amazon Web Services — for a brief introduction to S3 and EC2, view my previous blog post. If you’re ready for it, read [...]

  3. Gene Jannece Says:

    I ran across this post while reading up on Amazon EC2. You might want to take a look at Elastic Server (http://es.cohesiveft.com) as it might be just what you are looking for. Also, any feedback would be helpful.

Leave a Reply