Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

tests: fix race in test-http-curl-chunk-problem #9301

Conversation

misterdjules
Copy link

This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.

This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.
@misterdjules
Copy link
Author

This should be backported to v0.10, but there are other issues for v0.10 (see http://jenkins.nodejs.org/job/node-review-windows-julien/DESTCPU=ia32,label=windows/lastBuild/tapTestReport/simple.tap-240/) in this test that require more changes, so I'll fix that for v0.10 in another PR.

@mhdawson
Copy link
Member

mhdawson commented Mar 2, 2015

FYI - This test was failing consistently on one of our internal test machines, applying the patch resolved the issue.

@misterdjules
Copy link
Author

@mdawsonibm Thanks for the heads up!

If you have some time to review the code change and if you think it's the best way to fix it, could you please add "LGTM" in a comment?

Thanks again!

@misterdjules
Copy link
Author

/cc @joyent/node-coreteam.

@cjihrig
Copy link

cjihrig commented Mar 3, 2015

LGTM

1 similar comment
@mhdawson
Copy link
Member

mhdawson commented Mar 3, 2015

LGTM

@piscisaureus
Copy link

Another solution to wait for the "close" event on the child process object. It's guaranteed to fire after both the process has exited and all the stdio streams are closed.

But this works too - lgtm.

piscisaureus pushed a commit to nodejs/node that referenced this pull request Mar 3, 2015
This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.

PR: nodejs/node-v0.x-archive#9301
Reviewed-by: Bert Belder <[email protected]>
Reviewed-by: Michael Dawson <[email protected]>
Reviewed-by: Colin Ihrig <[email protected]>
@piscisaureus
Copy link

Landed in io.js - nodejs/node@1009130

@jasnell
Copy link
Member

jasnell commented Mar 3, 2015

LGTM

misterdjules pushed a commit to misterdjules/node that referenced this pull request Mar 3, 2015
This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.

PR: nodejs#9301
PR-URL: nodejs#9301
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Bert Belder <null>
misterdjules pushed a commit that referenced this pull request Mar 3, 2015
This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.

PR: #9301
PR-URL: #9301
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Bert Belder <[email protected]>
@misterdjules
Copy link
Author

@piscisaureus Indeed, that was my first solution, and then I thought that this one was more explicit. Thanks for bringing that up!

@misterdjules
Copy link
Author

Thank you, landed in d9a309f!

mhdawson pushed a commit to ibmruntimes/node that referenced this pull request Mar 5, 2015
This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.

PR: nodejs#9301
PR-URL: nodejs#9301
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Bert Belder <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants