-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cluster: suicide flag is not set on master when calling disconnect from a worker #3238
Comments
This commit causes Worker.prototype.disconnect() to send a suicide message to the cluster master. The function is also restructured to eliminate redundant code. Fixes: nodejs#3238
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event.
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event.
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: nodejs#4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-GH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: #4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-GH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: #4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-GH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: #4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: nodejs#4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: nodejs#4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no guarantee that the `suicide` property of a worker in the master process is going to be set when the `disconnect` and `exit` events are emitted. To fix it, wait for the ACK of the suicide message from the master before disconnecting the worker. Also, there's no need to send the suicide message from the worker if the disconnection has been initiated in the master. Add `test-cluster-disconnect-suicide-race` that forks a lot of workers to consistently reproduce the issue this patch tries to solve. Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect` cases. Also take into account that the `disconnect` event may be received after the `exit` event. PR-URL: nodejs#4349 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Came across same problem. I set a flag called "isSuicide" of worker Object: var cluster = require('cluster');
if (cluster.isMaster) {
// Master forks and listens for events
var worker = cluster.fork();
cluster.on('disconnect', function(worker){
worker.isSuicide = true;
console.log("disconnect", worker.suicide);
});
cluster.on('exit', function(worker){
worker.isSuicide && console.log("exit by suicide");
});
} else {
// Worker just disconnects
cluster.worker.disconnect();
} Is this a good practice for all node versions? |
Are you saying it will print true for v5 and later? @zhongkai No, it is not good practice. Your code sets suicide when the IPC channel is disconnected, but the 0.10 behaviour does it only when the worker deliberately disconnected. Change your line of code |
@sam-github Note that this issue was opened over a year ago and was supposedly fixed in f299d87. I don't know what the current behavior is or what is intended. |
Ah, didn't notice that. So, should be fixed. @zhongkai On what node version did you come across this problem? |
@sam-github , I'm sorry. I just want to make sure the solution is OK for version 0.12.x or not? |
Rename the test appropriately alongside mentioning the subsystem Also, make a few basic changes to make sure the test conforms to the standard test structure Refs: nodejs#19105 Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
Rename the tests appropriately alongside mentioning the subsystem. Also, make a few basic changes to make sure the test conforms to the standard test structure. This renames: - test-regress-nodejsGH-1531 - test-regress-nodejsGH-2245 - test-regress-nodejsGH-3238 - test-regress-nodejsGH-3542 - test-regress-nodejsGH-3739 - test-regress-nodejsGH-4256 PR-URL: nodejs#19212 Refs: nodejs#19105 Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com>
Rename the tests appropriately alongside mentioning the subsystem. Also, make a few basic changes to make sure the test conforms to the standard test structure. This renames: - test-regress-GH-1531 - test-regress-GH-2245 - test-regress-GH-3238 - test-regress-GH-3542 - test-regress-GH-3739 - test-regress-GH-4256 PR-URL: #19212 Refs: #19105 Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com>
Rename the tests appropriately alongside mentioning the subsystem. Also, make a few basic changes to make sure the test conforms to the standard test structure. This renames: - test-regress-GH-1531 - test-regress-GH-2245 - test-regress-GH-3238 - test-regress-GH-3542 - test-regress-GH-3739 - test-regress-GH-4256 PR-URL: #19212 Refs: #19105 Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com>
Rename the tests appropriately alongside mentioning the subsystem. Also, make a few basic changes to make sure the test conforms to the standard test structure. This renames: - test-regress-nodejsGH-1531 - test-regress-nodejsGH-2245 - test-regress-nodejsGH-3238 - test-regress-nodejsGH-3542 - test-regress-nodejsGH-3739 - test-regress-nodejsGH-4256 PR-URL: nodejs#19212 Refs: nodejs#19105 Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com>
Rename the tests appropriately alongside mentioning the subsystem. Also, make a few basic changes to make sure the test conforms to the standard test structure. This renames: - test-regress-GH-1531 - test-regress-GH-2245 - test-regress-GH-3238 - test-regress-GH-3542 - test-regress-GH-3739 - test-regress-GH-4256 PR-URL: #19212 Refs: #19105 Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com>
From the documentation:
worker.suicide
:worker.disconnect()
:Repro:
In node v0.10, both log statements would print
true
forworker.suicide
. In 41b75ca, which landed during the v0.11 branch, this was broken, and all versions up to node v4 will printfalse
. This is becauseworker.disconnect()
, when called from the worker, does not send thesuicide
message anymore -- onlyworker.destroy()
will send that message to the master.The text was updated successfully, but these errors were encountered: