-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: moved dgram bind shared ports to sequential #12999
Conversation
I'm not 100% on this one, just because of the necessity for the +1 mechanism, any advice would be appreciated. |
@@ -64,10 +64,10 @@ if (cluster.isMaster) { | |||
|
|||
socket1.bind({ | |||
address: 'localhost', | |||
port: common.PORT, | |||
port: 0, |
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.
If I'm reading the test correctly this can't be a dynamic port as the same port should be used by the two workers.
I think it's better to move this test in |
This patch does seem to work on my machine, not sure how. EDIT: That is to say, the test does pass. |
@gibfahn yes but I think it is not doing what the test is supposed to do, which is testing the |
Got it, I'll await feedback and go from there. |
No problem. |
In the other PR, is it not landing because it would be preferred to use process.send . I can make that edit if it solves this issue. |
#12452 seems ready to go apart from the merge conflicts. |
Yeah, it looks like the PR may have gone inactive. I'll wait for a little more info. |
@lpinca Ok, so I'm starting to understand the exclusive property better. I understand what you mean by the exclusive property not being utilized. So in my tests second round, it picks a new port and it does not conflict as it should. Is that deduction correct? |
Yup. |
Ok thank you |
I'm checking and I am getting that it is picking the same port, both times. @lpinca could you confirm?
by adding:
|
I started to reverse the changes in my local branch and debugged first with common.PORT then with an initial dynamic port. Results are similar. |
Would that behavior scale? I'm not sure, technically speaking. So I will stand by for further review and feedback. It's all the same to me. |
@arturgvieira you are right, it seems to pick up the same port also when using |
@lpinca I made some changes. This will get assigned a random port then maintain that port for the collision testing. Let me know what you think. I'm not sure how to remove the + 1 though. I tried and it lost the port collision issue. |
// the first worker should succeed | ||
port = socket1.address().port; | ||
socket2.bind({ | ||
port: 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.
There is no guarantee that this port is not being used by another process.
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.
Very true, I am trying to find some way to remove this type of syntax from the test.
socket1.bind({ | ||
address: 'localhost', | ||
port: common.PORT, | ||
port: port, |
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.
This is still 0
for the second worker.
exclusive: false | ||
}, () => { | ||
socket2.bind({ port: common.PORT + 1, exclusive: true }, () => { | ||
// the first worker should succeed | ||
port = socket1.address().port; |
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.
Please let me know if I am correct to say that the first worker reassigns port1 to the bound port in this line, so the second worker is using that port, not zero.
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.
No, this is not correct, each worker has its own context.
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 understand, that is why I am having problems with the port assignments. Thank you
I was able to reduce the usage of common.PORT, is this better? |
I still think it's better to just move this test to |
I agree, there are a couple other tests that might be the same. |
The usage of common.PORT could cause undesired port collisions when run in parallel. The following test was moved to sequential. test-dgram-bind-shared-ports.js Ref: #12376
@arturgvieira I merged #12452 because
Hope you don't mind. |
I don't mind. |
* add `mustCall` and `mustNotCall` to all callbacks * added `known_issue` for port binding PR-URL: nodejs#13100 Refs: nodejs#13055 Refs: nodejs#12999 Refs: nodejs#13526 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
* add `mustCall` and `mustNotCall` to all callbacks * added `known_issue` for port binding PR-URL: nodejs#13100 Refs: nodejs#13055 Refs: nodejs#12999 Refs: nodejs#13526 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
The usage of common.PORT could cause undesired port collisions when run
in parallel. The following test was moved to sequential.
test-dgram-bind-shared-ports.js
Ref: #12376
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test