cluster: remove handles when disconnecting worker #3677
Conversation
|
Looks like the CI had some issues with the test. |
|
Fix-ups applied. New run: https://ci.nodejs.org/job/node-test-pull-request/675/ |
|
LGTM, and I think the CI is ok. Looks like some Windows slaves went offline. |
| 'use strict'; | ||
|
|
||
| // Used in tests. | ||
| exports.handles = {}; |
There was a problem hiding this comment.
was going to suggest the same: https://code.google.com/p/v8/issues/detail?id=4518
|
Commit log is pretty shallow, may I ask you to add more information to it? |
|
Otherwise LGTM |
|
LGTM |
Due to the race window between the master's "disconnect" message and the worker's "handle received" message, connections sometimes got stuck in the pending handles queue when calling `worker.disconnect()` in the master process. The observable effect from the client's perspective was a TCP or HTTP connection that simply stalled. This commit fixes that by closing open handles in the master when the "disconnect" message is sent. Fixes: nodejs#3551 PR-URL: nodejs#3677 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Tagged lts-watch-v4.x but can I suggest letting this brew in master / v5 for 10 days or so? |
|
+1. Not planning another LTS update round for at least another week
|
Due to the race window between the master's "disconnect" message and the worker's "handle received" message, connections sometimes got stuck in the pending handles queue when calling `worker.disconnect()` in the master process. The observable effect from the client's perspective was a TCP or HTTP connection that simply stalled. This commit fixes that by closing open handles in the master when the "disconnect" message is sent. Fixes: #3551 PR-URL: #3677 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Any chance this to be ported to v0.12? |
|
Possibly. I put it on the watch list so it can be evaluated |
|
@bnoordhuis do you think it is ready to land in v4.x? |
|
@thealphanerd Maybe wait a little longer, it hasn't made its way into a release yet. It's scheduled for v5.1.0, see #3736 (comment). |
|
Yeah, likely best to hold off. Just in case. @bnoordhuis ... keep in mind that @thealphanerd was only talking about landing in |
|
indeed |
|
Oh, in that case go for it. |
Due to the race window between the master's "disconnect" message and the worker's "handle received" message, connections sometimes got stuck in the pending handles queue when calling `worker.disconnect()` in the master process. The observable effect from the client's perspective was a TCP or HTTP connection that simply stalled. This commit fixes that by closing open handles in the master when the "disconnect" message is sent. Fixes: #3551 PR-URL: #3677 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Due to the race window between the master's "disconnect" message and the worker's "handle received" message, connections sometimes got stuck in the pending handles queue when calling `worker.disconnect()` in the master process. The observable effect from the client's perspective was a TCP or HTTP connection that simply stalled. This commit fixes that by closing open handles in the master when the "disconnect" message is sent. Fixes: #3551 PR-URL: #3677 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Due to the race window between the master's "disconnect" message and the worker's "handle received" message, connections sometimes got stuck in the pending handles queue when calling `worker.disconnect()` in the master process. The observable effect from the client's perspective was a TCP or HTTP connection that simply stalled. This commit fixes that by closing open handles in the master when the "disconnect" message is sent. Fixes: #3551 PR-URL: #3677 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Due to the race window between the master's "disconnect" message and the worker's "handle received" message, connections sometimes got stuck in the pending handles queue when calling `worker.disconnect()` in the master process. The observable effect from the client's perspective was a TCP or HTTP connection that simply stalled. This commit fixes that by closing open handles in the master when the "disconnect" message is sent. Fixes: #3551 PR-URL: #3677 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Fixes: #3551
R=@indutny?
CI: https://ci.nodejs.org/job/node-test-pull-request/672/