Closed acarstoiu closed 8 years ago
I forgot to mention the Node.js version: 6.1.0.
Reproduceable with Node.js 6.2.1.
I finally managed to isolate (somehow) the cause in the pile of modules and interactions that comprise node-spy. It's a function call scheduled with process.nextTick
that just doesn't get called until the next use of timers (the event loop is simply blocked or so it seems). The blocked call is here in readable-stream when trying to send the headers frame.
Unfortunately this problem shows up only when some in-house developed native module gets called before each call to node-spdy - and apparently every second call heals Node's frozen state. I never suspected this module, nor do I suspect it now; this looks like a V8 bug which happens to manifest when some native code is also run. Anyway, we'll have a look at it, just in case.
On a side note, the existence of two TCP connections was due to my code, sorry about that.
After quite some testing with the latest node-spdy version (3.3.3) in the view of sending Apple push notifications using their HTTP 2 API, I isolated this strange behaviour. Given an agent configured with the following options
the second attempt to send a notification is delayed until the third one is made, the fourth attempt until the fifth is made and so on. And it's not a callback timing problem; no, those notifications after the first one are really received in pairs on the destination Apple device.
Here is a full log for the first three requests, spaced at 30s (this interval is irrelevant, at 15s all happens the same):
The lines prefixed with
>>>
are mine, from outside node-spdy. I noticed a few things that may be related:Lastly and unrelated, there is something about which I'm curious: the design choice of opening the connection(s) at agent creation time. For one, the connection creation should be delayed until it is truely needed. Secondly, this forces the user to bind the agent to a certain destination host-port pair and use different agents for different destinations.