inactivity timeout oddities #149

jormon opened this Issue Oct 26, 2011 · 3 comments


None yet
3 participants

jormon commented Oct 26, 2011


The above commit exposes some strange behavior with regards to the inactivity timeout exposed by em-http-request. In both of the new tests introduced, the request should timeout in 10-11 seconds given the 1 second heartbeat interval. Instead both tests timeout in ~15s. I realize it's not feasible to have tests of this length in the codebase, but I'm curious as to what the ultimate cause of this problem is and if there's anything we can do to resolve it.

I tested this code in two environments. It failed the two new tests the same way in each environment:

  • Mac OSX 10.7, rvm 1.8.0, ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.1.0]
    • Linux 2.6.18-238.19.1.el5 x86_64, rvm 1.2.4, ruby 1.9.2p174 (2011-01-28 revision 30696) [x86_64-linux]

igrigorik commented Oct 26, 2011

Latest version of eventmachine, correct? I believe this is due to the semantics of how the timeouts are set in EM. There is the default 5s connection timeout that em-http sets, and then there is the 10s inactivity timeout. What you're seeing is 5+10s timeout.

Admittedly, this is / can be confusing, and something I've raised before as well.. although that's not em-http, but eventmachine itself. /cc @tmm1


jormon commented Oct 27, 2011

Yeah, this was just the default bundle install off of your master which pulls eventmachine (1.0.0.beta.4).

Well, I guess that does explain it. So it sounds like if I want to have a connection that times out with no response after X seconds, I have to set inactivity_timeout to X - connect_timeout. Truly strange semantics from EM. :/ Thanks for the prompt response!

@jormon jormon closed this Oct 27, 2011

tmm1 added a commit to eventmachine/eventmachine that referenced this issue Mar 8, 2013

fix long-standing pending_connect/inactivity timeout issue
this reverts a change made for #374, which inadvertently disabled inactivity
timeouts altogether.

instead we always QueueHeartbeat when bConnectPending changes, so
GetNextHeartbeat can calculate a timeout based on the new connection
state. i confirmed this fixes the broken test on master, and the original
"20s delay" bug (using the repro in #393).

this should also address the timeout stacking issue reported in
igrigorik/em-http-request#149, as well as the original report in

tmm1 commented Mar 8, 2013

Note that this behavior has changed as of EM 1.0.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment