-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
test: use dynamic port in test-dgram-bind-shared-ports #12452
Conversation
socket2.bind({ port: common.PORT + 1, exclusive: true }, () => { | ||
}, common.mustCall(() => { | ||
socket2.bind({ | ||
port: socket1.address().port + 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is correct. There's no guarantee that this port is in use by a different process. TBH I'm not sure there's a better solution than using common.PORT
, maybe someone has a better idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason that this port has to be the first port + 1? Couldn't it just be port: 0
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That won't work as it would use a different port on every worker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, both workers need to use the same two port numbers for both sockets. (In other words, each worker has two sockets. And those sockets should have duplicate ports across workers.)
I think the choices are:
- introduce code to communicate ports between the two workers, or
- move the test as-is to
sequential
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, the change already in place in this test is incorrect because it guarantees that socket1 doesn't use the same port in worker1 and worker2. Both workers should use the same port. (Nothing to feel bad about with missing that. It's not a completely intuitive test. It certainly took me a while to figure out what was going on.)
I think the way to go is to move the test as it currently exists on the master branch from the parallel
directory to the sequential
directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the change already in place in this test is incorrect because it guarantees that socket1 doesn't use the same port in worker1 and worker2.
I'm not sure about this. I think that socket1
being a non-exclusive socket will use the same port in both workers. That's not the case with socket2
though.
I think the way to go is to move the test as it currently exists on the master branch from the parallel directory to the sequential directory.
I agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using socket1.address().port +1
is still a problem. See comments. This one might be do-able using operating system-assigned ports, but the easiest thing to do might be to move it from parallel
to sequential
and don't make any changes to the code. If someone wants to refactor it to use dynamic ports at a later date, then great. If not, that's fine too.
I'm lost. The original test was using |
No, the original test was fine. The test creates two workers. Each worker creates two dgram sockets. One is on By changing |
I see. Thanks for clearing that up. What would you recommend me doing? |
I would recommend rewriting the test so that the ports selected by the first worker can be communicated to the second worker so it can use the same ports. Probably use |
@Trott is there a place where we can chat about node? I would love to get some more insights from you. I'll try to make these changes. |
@rafaelfragosom A large portion of the regular contributors to Node.js (including me) are often in the #node-dev channel on Freenode IRC, so that might be a place to get insights from a bunch of people. |
0c0e3c5
to
70981ac
Compare
@Trott I moved the test to sequential and restored the use of common.PORT(). I'll be glad to understand and help with the other approach you mentioned (dynamic ports). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@rafaelfragosom can you please rebase against master? |
Use of common.PORT in parallel tests is not completely safe (because the same port can be previously assigned to another test running in parallel if that test uses port 0 to get an arbitrary available port). Remove common.PORT from test-dgram-bind-shared-ports.
Adding a common.mustCall() to socket1 callback on test-dgram-bind-shared-ports to make sure the callback is being called.
As was pointed out on [this review](nodejs#12452 (review)) I moved the test to the sequential folder. Refs: nodejs#12376
Restoring the contents of the test to it's original with common.PORT() Refs: nodejs#12376
31c426a
to
07d3bf8
Compare
@lpinca I think I just did it, let me know. |
@rafaelfragosom thank you. |
PR-URL: nodejs#12452 Ref: nodejs#12376 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Landed in 84fc069. |
PR-URL: nodejs#12452 Ref: nodejs#12376 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Use of common.PORT in parallel tests is not completely safe (because
the same port can be previously assigned to another test running in
parallel if that test uses port 0 to get an arbitrary available port).
Remove common.PORT from test-dgram-bind-shared-ports.
Refs: #12376
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test