TimeoutError seen when connecting to EC2 Metadata service on v0.10.30 using aws-sdk 1.18.0 node module

[huckphin]

I am having troubles starting our application with node v0.10.30. I am currently observing a TimeoutError when the aws-sdk attempts to grab data from the EC2 Metadata Service. Here is the stack trace that I am seeing:

2014/08/07 18:21:44.299 [server] : [TimeoutError] Connection timed out after 3000ms
TimeoutError: Connection timed out after 3000ms
    at ClientRequest.<anonymous> (XXXXXXXX/node_modules/aws-sdk/lib/http/node.js:51:34)
    at ClientRequest.g (events.js:180:16)
    at ClientRequest.emit (events.js:92:17)
    at Socket.emitTimeout (http.js:1797:10)
    at Socket.g (events.js:180:16)
    at Socket.emit (events.js:92:17)
    at Socket._onTimeout (net.js:326:8)
    at Timer.unrefTimeout [as ontimeout] (timers.js:427:13)

Inspecting the version of Amazon SDK that we are using, this is the aws-sdk node module 1.18.0. Using the same code base and the same node modules, I prepared a system that had the following node versions built:

• 0.10.26
• 0.10.27
• 0.10.28
• 0.10.29
• 0.10.30

The only version that I am seeing this error on is 0.10.30. Since I was able to reliably produce the issue, I ran a git bisect on the code. git bisect said that this was the first bad commit:

befbbad0513c5f1075c573570a678d148b645a82 is the first bad commit
commit befbbad0513c5f1075c573570a678d148b645a82
Author: Julien Gilli <[email protected]>
Date:   Tue Jul 22 18:03:10 2014 -0700

    timers: backport f8193ab

    Original commit message:

     timers: use uv_now instead of Date.now

     This saves a few calls to gettimeofday which can be expensive, and
     potentially subject to clock drift. Instead use the loop time which
     uses hrtime internally.

    In addition to the backport, this commit:
     - keeps _idleStart timers' property which is still set to
       Date.now() to avoid breaking existing code that uses it, even if
       its use is discouraged.
     - adds automated tests. These tests use a specific branch of
       libfaketime that hasn't been submitted upstream yet. libfaketime
       is git cloned if needed when running automated tests.

    Signed-off-by: Timothy J Fontaine <[email protected]>

:100644 100644 177514422a5fb1cb912a838a7fc68d78bbcf4c36 766766e152dd7e4d1292cbfac9dea4fe56de9073 M  .gitignore
:100644 100644 281c283ffbd0254bda43b6d2938739359ba386c2 3464c2e2f16fce10fb396f8113fa69205e1f7c48 M  Makefile
:040000 040000 fa0bca48d90dadbc116553e43cd3352c86220e5d fe4d4b85ecbee16b90604e0778c6deca42847c0a M  lib
:040000 040000 48b7de665d7d0d6f99b94921bcde1aa07b715d80 aa7821eed799a9696ca881e858ca456847169e35 M  src
:040000 040000 6e3b7511bdeb26537bec10a144c7b9426c7e2015 c4a2f3dce077306d1f2a73b9e555bb6b134668df M  test
:040000 040000 00af0fd4f217166eae6e59eb3fab8b2f0b84d34f 151a28e2e020869e0dcf70ff7fa37247f0141812 M  tools

To test this out, I checked out the v0.10.30 branch. I reverted this
commit, and did a new build of node with this commit out.

When I built node 10.30 without this patch, the errors went
away.

[misterdjules]

@huckphin Thank you for reporting this issue! It's been fixed by this PR. Could you please confirm that this commit on the v0.10 branch fixes your issue?

AFAIK, this fix will be included in the next release, @tjfontaine could you please confirm?

[huckphin]

Thanks for the fast turn around. I confirmed that this PR does in fact fix my problem.

Thanks!

[misterdjules]

@huckphin Excellent, thank you for your feedback!

[tjfontaine]

Thanks closing, a new 0.10 will be released asap (fixed in 6f04394)