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

test: use dynamic port in test-dgram-bind-shared-ports #12452

Closed
wants to merge 4 commits into from

Conversation

@orafaelfragoso
Copy link
Contributor

commented Apr 16, 2017

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), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test

test/sequential/test-dgram-bind-shared-ports.js Outdated
socket2.bind({ port: common.PORT + 1, exclusive: true }, () => {
}, common.mustCall(() => {
socket2.bind({
port: socket1.address().port + 1,

This comment has been minimized.

Copy link
@santigimeno

santigimeno Apr 16, 2017

Member

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.

This comment has been minimized.

Copy link
@gibfahn

gibfahn Apr 16, 2017

Member

Is there a reason that this port has to be the first port + 1? Couldn't it just be port: 0 as well?

This comment has been minimized.

Copy link
@santigimeno

santigimeno Apr 16, 2017

Member

That won't work as it would use a different port on every worker.

This comment has been minimized.

Copy link
@Trott

Trott Apr 16, 2017

Member

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

This comment has been minimized.

Copy link
@Trott

Trott Apr 16, 2017

Member

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.

This comment has been minimized.

Copy link
@santigimeno

santigimeno Apr 17, 2017

Member

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.

@Trott
Copy link
Member

left a comment

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.

@orafaelfragoso

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2017

I'm lost. The original test was using common.PORT + 1. So that means it was wrong from the start?

@Trott

This comment has been minimized.

Copy link
Member

commented Apr 18, 2017

I'm lost. The original test was using common.PORT + 1. So that means it was wrong from the start?

No, the original test was fine.

The test creates two workers. Each worker creates two dgram sockets. One is on common.PORT and one is on common.PORT + 1. The whole point of the test is that both workers each try to use the same ports. The first dgram socket is configured in such a way that it is not a problem that they are using the same port. The second dgram socket is configured in such a way that this results in an error. The test was checking to see if that behavior was being seen or not.

By changing common.PORT to 0, the port collision (which is an essential part of the test) is removed.

@orafaelfragoso

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2017

I see. Thanks for clearing that up.

What would you recommend me doing?

@Trott

This comment has been minimized.

Copy link
Member

commented Apr 18, 2017

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 process.send() in worker1 to send the port information to the cluster master process, which can then send it to worker2.

@orafaelfragoso

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2017

@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.

@Trott

This comment has been minimized.

Copy link
Member

commented Apr 18, 2017

@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.

@orafaelfragoso orafaelfragoso force-pushed the orafaelfragoso:test-dgram branch Apr 26, 2017

@orafaelfragoso

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2017

@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).

@Trott
Trott approved these changes Apr 27, 2017
Copy link
Member

left a comment

LGTM

@Trott

This comment has been minimized.

@santigimeno santigimeno referenced this pull request Apr 28, 2017
3 of 3 tasks complete
@arturgvieira arturgvieira referenced this pull request May 12, 2017
2 of 2 tasks complete
@lpinca

This comment has been minimized.

Copy link
Member

commented May 13, 2017

@rafaelfragosom can you please rebase against master?

test: use dynamic port in test-dgram-bind-shared-ports
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.
test: adding common.mustCall() to socket1 callback
Adding a common.mustCall() to socket1 callback on
test-dgram-bind-shared-ports to make sure the callback
is being called.
test: moved test-dgram-bind-shared-ports to sequential
As was pointed out on [this
review](#12452 (review))
I moved the test to the sequential folder.

Refs: #12376
test: restoring test-dgram-bind-shared-ports to original
Restoring the contents of the test to it's original with common.PORT()

Refs: #12376

@orafaelfragoso orafaelfragoso force-pushed the orafaelfragoso:test-dgram branch to 07d3bf8 May 13, 2017

@orafaelfragoso

This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2017

@lpinca I think I just did it, let me know.

@lpinca
lpinca approved these changes May 13, 2017
@lpinca

This comment has been minimized.

Copy link
Member

commented May 13, 2017

@rafaelfragosom thank you.

@lpinca

This comment has been minimized.

Copy link
Member

commented May 13, 2017

lpinca added a commit to lpinca/node that referenced this pull request May 13, 2017
test: move test-dgram-bind-shared-ports to sequential
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>
@lpinca

This comment has been minimized.

Copy link
Member

commented May 13, 2017

Landed in 84fc069.

@lpinca lpinca closed this May 13, 2017

@Trott Trott referenced this pull request May 13, 2017
55 of 64 tasks complete
anchnk pushed a commit to anchnk/node that referenced this pull request May 19, 2017
test: move test-dgram-bind-shared-ports to sequential
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>
@jasnell jasnell referenced this pull request May 28, 2017
@gibfahn gibfahn referenced this pull request Jun 15, 2017
2 of 3 tasks complete
MylesBorins added a commit that referenced this pull request Jun 22, 2017
test: move test-dgram-bind-shared-ports to sequential
PR-URL: #12452
Ref: #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>
MylesBorins added a commit that referenced this pull request Jul 11, 2017
test: move test-dgram-bind-shared-ports to sequential
PR-URL: #12452
Ref: #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>
@MylesBorins MylesBorins referenced this pull request Jul 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.