-
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: improve test-https-server-keep-alive-timeout #13312
Conversation
})); | ||
}); | ||
|
||
test(function serverNoEndKeepAliveTimeoutWithPipeline(cb) { | ||
let socket; | ||
let destroyedSockets = 0; | ||
let timeoutCount = 0; | ||
let requestCount = 0; | ||
process.on('exit', () => { | ||
assert.strictEqual(timeoutCount, 1); | ||
assert.strictEqual(requestCount, 3); |
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.
assert.strictEqual(requestCount, 3); [](start = 4, length = 36)
Do we need this since you are clearing the interval with requestCount === 3
?
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 left it in to make sure it doesn't subsequently increase to 4 or higher. Probably not needed but also maybe doesn't hurt?
@@ -31,20 +31,18 @@ function run() { | |||
|
|||
test(function serverKeepAliveTimeoutWithPipeline(cb) { | |||
let socket; | |||
let destroyedSockets = 0; | |||
let timeoutCount = 0; | |||
let requestCount = 0; | |||
process.on('exit', function() { | |||
assert.strictEqual(timeoutCount, 1); | |||
assert.strictEqual(requestCount, 3); |
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.
Can the test be refactored to eliminate the need for the exit handler?
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.
Yes, but I'd rather that be in a separate PR.
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 agree that since this PR is focused on robustness, it will be "offtopic" to remove, but now it "cries out" to remove this in favor of a mustCall(x,3)
in line (new file) 37, and corresponding 63 & 66.
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.
Thanks!
Maybe I'm missing something but why is the polling/interval needed? Isn't wrapping the callback of |
@lpinca I added an additional commit to remove the interval. Seems to work (including under load). LGTY? |
LGTM. It's a lot cleaner 👍 . |
Personally I like the |
I don't think |
What @Trott said. In this case the interval was cleared when the |
(Oh, and the 500 ms |
Yeah ok, but still the Again I'm not objecting, just thinking out loud. I'm fine with K.I.S.S. |
I don't think this is relevant. As it was, the interval would have never been cleared if I wonder if that small value (50) for |
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.
just nits
@@ -31,20 +31,18 @@ function run() { | |||
|
|||
test(function serverKeepAliveTimeoutWithPipeline(cb) { | |||
let socket; | |||
let destroyedSockets = 0; | |||
let timeoutCount = 0; | |||
let requestCount = 0; | |||
process.on('exit', function() { | |||
assert.strictEqual(timeoutCount, 1); | |||
assert.strictEqual(requestCount, 3); |
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 agree that since this PR is focused on robustness, it will be "offtopic" to remove, but now it "cries out" to remove this in favor of a mustCall(x,3)
in line (new file) 37, and corresponding 63 & 66.
socket.destroy(); | ||
}); | ||
server.close(); |
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.
nit: just for readability, could you put comment that // this ends the test
or do a:
function endTest(socket) {
socket.destroy();
server.close();
cb();
}
...
server.setTimeout(500, common.mustCall(endTest));
Here and in L41?
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.
Ack
The test is flaky under load. These changes greatly improve reliability. * Use a recurring interval to determine when the test should end rather than a timer. * Increase server timeout to 500ms to allow for events being delayed by system load Changing to an interval has the added benefit of reducing the test run time from over 2 seconds to under 1 second. Fixes: nodejs#13307
The test is flaky under load. These changes greatly improve reliability. * Use a recurring interval to determine when the test should end rather than a timer. * Increase server timeout to 500ms to allow for events being delayed by system load Changing to an interval has the added benefit of reducing the test run time from over 2 seconds to under 1 second. Fixes: #13307 PR-URL: #13312 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Alexey Orlenko <[email protected]>
Landed in ce5745b |
The test is flaky under load. These changes greatly improve reliability. * Use a recurring interval to determine when the test should end rather than a timer. * Increase server timeout to 500ms to allow for events being delayed by system load Changing to an interval has the added benefit of reducing the test run time from over 2 seconds to under 1 second. Fixes: #13307 PR-URL: #13312 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Alexey Orlenko <[email protected]>
Make the same reliability changes that were applied to the https test in ce5745b. Refs: #13312 PR-URL: #13448 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Alexey Orlenko <[email protected]>
Make the same reliability changes that were applied to the https test in ce5745b. Refs: #13312 PR-URL: #13448 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Alexey Orlenko <[email protected]>
The test is flaky under load. These changes greatly improve reliability.
than a timer.
system load
Changing to an interval has the added benefit of reducing the test run
time from over 2 seconds to under 1 second.
Fixes: #13307
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test https