http: unref socket timer on parser execute#6286
http: unref socket timer on parser execute#6286indutny wants to merge 3 commits intonodejs:masterfrom
Conversation
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: nodejs#5899
|
Gosh, timing issues on FreeBSD CI slave. One more try after the fix: https://ci.nodejs.org/job/node-test-pull-request/2327/ |
|
Quick question, does this apply to v4 as well? |
|
It does. |
|
Thank you! |
|
cc @nodejs/http @bnoordhuis @trevnorris @jasnell |
| assert(false, 'Should not happen'); | ||
| }); | ||
| req.resume(); | ||
| req.once('end', () => { |
There was a problem hiding this comment.
nit: wrap this in common.mustCall() ?
|
LGTM with a couple nits in the test. |
|
@indutny glad if I've helped & thank you for the fix :) |
| setTimeout(() => { | ||
| clearInterval(interval); | ||
| req.end(); | ||
| }, 400); |
There was a problem hiding this comment.
This timeout value should probably be wrapped with common.platformTimeout()?
|
All fixed, new CI: https://ci.nodejs.org/job/node-test-pull-request/2345/ |
|
Landed in ec2822a, thank you! |
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: #5899 PR-URL: #6286 Reviewed-By: James M Snell <jasnell@gmail.com>
|
Thanks for the fix! |
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: #5899 PR-URL: #6286 Reviewed-By: James M Snell <jasnell@gmail.com>
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: #5899 PR-URL: #6286 Reviewed-By: James M Snell <jasnell@gmail.com>
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: nodejs#5899 PR-URL: nodejs#6286 Reviewed-By: James M Snell <jasnell@gmail.com>
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: #5899 PR-URL: #6286 Reviewed-By: James M Snell <jasnell@gmail.com>
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: #5899 PR-URL: #6286 Reviewed-By: James M Snell <jasnell@gmail.com>
When underlying `net.Socket` instance is consumed in http server - no `data` events are emitted, and thus `socket.setTimeout` fires the callback even if the data is constantly flowing into the socket. Fix this by calling `socket._unrefTimer()` on every `onParserExecute` call. Fix: #5899 PR-URL: #6286 Reviewed-By: James M Snell <jasnell@gmail.com>
|
Looks like FreeBSD timing issues are back with this: #7643 I guess if there was some way to make this not dependent on a timer race, that would have happened, yeah? :-/ @nodejs/testing |
|
Actually, I think I've fixed it. PR coming soon... |
Checklist
Affected core subsystem(s)
http
Description of change
When underlying
net.Socketinstance is consumed in http server - nodataevents are emitted, and thussocket.setTimeoutfires thecallback even if the data is constantly flowing into the socket.
Fix this by calling
socket._unrefTimer()on everyonParserExecutecall.
Fix: #5899