Skip to content
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: migrate from worker.suicide #3743

Merged
merged 1 commit into from
Apr 26, 2016
Merged

Conversation

evanlucas
Copy link
Contributor

@evanlucas evanlucas commented Nov 10, 2015

Replace it with worker.exitedAfterDisconnect. Print deprecation message when
getting or setting until it is removed.

Ref: #3721

@MylesBorins
Copy link
Contributor

LGTM

@MylesBorins MylesBorins added cluster Issues and PRs related to the cluster subsystem. semver-minor PRs that contain new features and should be released in the next minor version. labels Nov 10, 2015
@MylesBorins
Copy link
Contributor

Test suite passes locally fwiw

if (worker.suicide === true) {
console.log('Oh, it was just suicide\' – no need to worry').
if (worker.voluntaryExit === true) {
console.log('Oh, it was just voluntary\' – no need to worry').
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add exit, it was just voluntary -> it was just voluntary exit

@JungMinu
Copy link
Member

LGTM with one comment

@mikeal
Copy link
Contributor

mikeal commented Nov 10, 2015

"deprecate" is the wrong term here since you are ensuring exisiting compatibility. maybe "migrating" instead?

@mikeal
Copy link
Contributor

mikeal commented Nov 10, 2015

also, maybe not print the deprecation warning until the next major release.

@@ -427,8 +442,8 @@ function masterInit() {
queryServer(worker, message);
else if (message.act === 'listening')
listening(worker, message);
else if (message.act === 'suicide')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need to watch for the 'suicide' action here to guarantee compatibility?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since the message should only be internal, I don't think so. Unless you or someone else feel differently about it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me 😄

@jasnell
Copy link
Member

jasnell commented Nov 10, 2015

LGTM but we need to be clear about the impact of this, however. It is quite likely a semver-major change (any time we talk about changing event names and deprecating existing terms we likely have to consider it a semver-major). That means getting a deprecation notice into v5 first, then not landing the actual change until v6.

@mikeal
Copy link
Contributor

mikeal commented Nov 10, 2015

@jasnell if it's backwards compatible why would it be a semver-major change?

@jasnell
Copy link
Member

jasnell commented Nov 10, 2015

I said "likely" ;-). The one part of this change that is potentially not backwards compatible is the event that's being triggered (https://github.com/nodejs/node/pull/3743/files#diff-0faa53fc02580d5de2ebb484c41d691cR696). Specifically, are we reasonably certain that this isn't breaking?

@Qard
Copy link
Member

Qard commented Nov 10, 2015

A more boolean terminology like exitedVoluntarily might be a bit better. I could see someone thinking voluntaryExit is a function name.

@evanlucas
Copy link
Contributor Author

@jasnell I believe that those messages are only sent to/from a cluster by the cluster and workers.

@jasnell
Copy link
Member

jasnell commented Nov 10, 2015

Ok. If we're reasonably sure that it's not breaking, I'm good with semver-minor.

@evanlucas
Copy link
Contributor Author

@Qard I'm fine with either. If you feel strongly about it, I will change it

return this.voluntaryExit;
},
set: function(val) {
// TODO: Print deprecation message.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this message include information about when (date or version) to expect deprecation to become removal?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be slated for a major version. Honestly, we should just merge this and then open another PR right away with the deprecation warning since master is v6.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I just add a second commit? That way we can cherry-pick the first over to v5 and not the actual deprecation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes :)

@Fishrock123
Copy link
Contributor

@ChALkeR I know you didn't feel for it, but could you run some npm analysis on the usage of this API if possible?

(Also cc @chrisdickinson)

@Fishrock123
Copy link
Contributor

As others have said I also think it may be worthwhile to think of a version of voluntaryExit that makes a little more sense as a boolean, if that's the kind of thing we want.

@evanlucas
Copy link
Contributor Author

Although long, if that is the way we want to go, I think exitedVoluntarily is the best

@Fishrock123
Copy link
Contributor

So long as we can avoid naming like exitedVoluntarilyFromWorkerProcess ala what a certain other programming language is often blamed for I think we are mostly fine.

@evanlucas
Copy link
Contributor Author

Updated to change to exitedVoluntarily. Also includes a commit that prints a deprecation warning.

@mikeal
Copy link
Contributor

mikeal commented Nov 10, 2015

hrm... I may have misspoke. since we tag the PR to automatically do the version updates we may need two PRs for the two commits since one is semver-minor and one is semver-major.

@evanlucas evanlucas changed the title cluster: deprecate worker.suicide cluster: migrate from worker.suicide Nov 10, 2015
@ChALkeR
Copy link
Member

ChALkeR commented Aug 5, 2016

Btw, this wasn't backported to 4.x, was it? Perhaps it is too late now as 4.5 already got rcs (cc @thealphanerd), but if there would be 4.6 sometime, it could make sense to backport it the other way around and without the deprecation — i.e. make .exitedAfterDisconnect a getter/setter alias to .suicide in a semver-minor version of 4.x.

@jasnell
Copy link
Member

jasnell commented Aug 5, 2016

+1 SGTM

On Friday, August 5, 2016, Сковорода Никита Андреевич <
notifications@github.com> wrote:

Btw, this wasn't backported to 4.x, was it? Perhaps it is too late now as
4.5 already got rcs, but if there would be 4.6 sometime, it could make
sense to backport it the other way around and without the deprecation —
i.e. make .exitedAfterDisconnect a getter/setter alias to .suicide.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3743 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eSlRqcZPIm26xbWiN2nT7qPSqJATks5qczxGgaJpZM4Gfr24
.

@ChALkeR
Copy link
Member

ChALkeR commented Aug 5, 2016

Because given our LTS timeline, if we don't make 4.x support .exitedAfterDisconnect, then hard-deprecating .suicide until at least 10.x won't be reasonable, because that would force libraries to resort to detection mechanisms.

@evanlucas
Copy link
Contributor Author

I'll submit a backport PR today

evanlucas added a commit to evanlucas/node that referenced this pull request Aug 7, 2016
This is a backport of 4f619bd which
migrates from worker.suicide to worker.exitedAfterDisconnect.

Related: nodejs#3743
jasnell pushed a commit that referenced this pull request Aug 12, 2016
This is a backport of 4f619bd which
migrates from worker.suicide to worker.exitedAfterDisconnect.

Refs: #3743
PR-URL: #7998
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
nimit95 added a commit to nimit95/node that referenced this pull request Jul 26, 2019
The defaul value of worker.exitedAfterDisconnect is undefined. If the
worker dies on its own the value is changed to false and doesn't
remains undefined. While the documentation just mentions 'Set by
calling .kill() or .disconnect(). Until then, it is undefined.'.
Making the default value as false in worker.js

Fixes: nodejs#28837
Refs: nodejs#3743
nimit95 added a commit to nimit95/node that referenced this pull request Jul 26, 2019
Fixed the documentaion to reflect the changes in the default value
of worker.exitedAfterDisconnect

Fixes: nodejs#28837
Refs: nodejs#3743
nimit95 added a commit to nimit95/node that referenced this pull request Jul 26, 2019
The test checka for the exit code of the worker. cluster on exit
must be called. And the value for exitedAfterDisconnect should be false

Fixes: nodejs#28837
Refs: nodejs#3743
nimit95 added a commit to nimit95/node that referenced this pull request Jul 26, 2019
fixed the test that checked for default value undefined to false and renamed the test that checks for the value exitedAfterDisconnect if the worker
exits on its own.

Fixes: nodejs#28837
Refs: nodejs#3743
nimit95 added a commit to nimit95/node that referenced this pull request Sep 2, 2019
Fixed the documentation to reflect the changes in the default value
of worker.exitedAfterDisconnect

Fixes: nodejs#28837
Refs: nodejs#3743
danbev pushed a commit that referenced this pull request Sep 9, 2019
Fixed the documentation to reflect the changes in the default value
of worker.exitedAfterDisconnect

PR-URL: #29404
Fixes: #28837
Refs: #3743
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
targos pushed a commit that referenced this pull request Sep 20, 2019
Fixed the documentation to reflect the changes in the default value
of worker.exitedAfterDisconnect

PR-URL: #29404
Fixes: #28837
Refs: #3743
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
BridgeAR pushed a commit that referenced this pull request Sep 25, 2019
Fixed the documentation to reflect the changes in the default value
of worker.exitedAfterDisconnect

PR-URL: #29404
Fixes: #28837
Refs: #3743
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cluster Issues and PRs related to the cluster subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.