Uh oh!
There was an error while loading. Please reload this page.
net: shutdown gracefully - #1164
Conversation
indutny
commented
Mar 16, 2015
cc @piscisaureus should fix that nasty issue on windows. Going to test it now. |
calvinmetcalf
commented
Mar 16, 2015
you beat me to opening this, through I was going call it _end for symmetry with the end method |
indutny
commented
Mar 16, 2015
Do not land this yet, it doesn't fix the issue on windows. Needs some investigation. |
indutny
commented
Mar 16, 2015
Going to push here a couple of commits just for my own testing, sorry about this! |
indutny
commented
Mar 17, 2015
Ok, now it seems to be ready. @piscisaureus : this fixes the issue on windows once and for free ;) |
Fishrock123
commented
Mar 17, 2015
piscisaureus
commented
Mar 17, 2015
First of all, great work for digging into this and finding a fix. I have one question though. Back in the day there we deliberately chose not to gracefully close TCP connections when serving http, for performance reasons. Instead we'd just wait until all writes were completed, and then close the connection. The kernel then takes care of doing a graceful close (note that it's still a graceful close!). This is also the source of the subtle differences between the various finalization methods for TCP connections:
I think it would be best if the TLS wrap also supported this kind of behavior. I am not sure I completely understand how this patch affects that behavior. @bnoordhuis I would also like to hear some deep thoughts from you. |
indutny
commented
Mar 17, 2015
@piscisaureus I guess we could use it for TLS only then, putting this |
Fishrock123
commented
Mar 17, 2015
Looks like this cropped up on both windows machines: |
indutny
commented
Mar 17, 2015
@Fishrock123 yeah, I see it on my windows box too. Looking. |
indutny
commented
Mar 18, 2015
Ok, let's hope this one is a green now: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/316/ |
bnoordhuis
commented
Mar 18, 2015
What's the reason for always calling shutdown() on TCP sockets now? I have a gut feeling that's going to impact performance for no good reason. |
Fishrock123
commented
Mar 18, 2015
|
indutny
commented
Mar 18, 2015
@Fishrock123 is it related or not? @bnoordhuis I was trying to figure out |
Fishrock123
commented
Mar 18, 2015
@indutny I think you'd be able to tell better than me, but I'd wager to say it might be, given it tests functionality related to flush and this changes some stream flush code. |
indutny
commented
Mar 18, 2015
@Fishrock123 I was wrong to close it yesterday :) Now I see that it should be still useful. |
indutny
commented
Mar 18, 2015
CI again: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/324/ I don't see any failures except fs-access on my box. |
indutny
commented
Mar 18, 2015
It appears to me that parallel/test-net-reconnect-error is just very slow on windows. |
indutny
commented
Mar 18, 2015
Looking into other tests too. |
indutny
commented
Mar 18, 2015
parallel/test-http-curl-chunk-problem works just fine without timing out. |
indutny
commented
Mar 18, 2015
Same about parallel/test-process-kill-null, all of the rest works too. |
indutny
commented
Mar 18, 2015
@piscisaureus may I ask you to take a look at these? I'm not sure how I could reproduce... |
Fishrock123
commented
Mar 19, 2015
@indutny Odd, that test failure did not manifest itself again. The timeouts seem standard and almost certainly are not related to the PR. (That should be for a different issue.) |
c57e567 to
aff0cb3Compareindutny
commented
Mar 19, 2015
jbergstroem
commented
Mar 19, 2015
Looks like the os x box fails |
Fishrock123
commented
Mar 19, 2015
An OS X failure has popped up, I reported this one in #1100 as I had previously seen it locally. This is the first time I've seen it on the CI. (should be unrelated) |
It's not clear what additional tests are wanted. The current malformed URL test seems adequate. PR-URL: nodejs#1875 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com>
`printDeprecationMessage` is used to deprecate modules and execution branches. PR-URL: nodejs#1822 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
It makes no sense to allow people use constants from `smalloc`, since it will be removed completely eventually. PR-URL: nodejs#1822 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When loading session, OCSP response, SNI, always check that the `self._handle` is present. If it is not - the socket was closed - and we should emit the error instead of throwing an uncaught exception. Fix: nodejs/node-v0.x-archive#8780Fix: nodejs#1696 PR-URL: nodejs#1702 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
* Destroy `SSL*` and friends on a next tick to make sure that we are not doing it in one of the OpenSSL callbacks * Add more checks to the C++ methods that might be invoked during destructor's pending queue cleanup Fix: nodejs/node-v0.x-archive#8780Fix: nodejs#1696 PR-URL: nodejs#1702 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
PR-URL: nodejs#1702 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Add string encoding option for fs.createReadStream and fs.createWriteStream. and check argument type more strictly PR-URL: nodejs#1845 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
When using `iojs debug -p <pid>` with an invalid pid, the debugger printed an internal error message because it wasn't smart enough to figure out that the target process didn't exist. Now it is. PR-URL: nodejs#1863 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Yosuke Furukawa <yosuke.furukawa@gmail.com>
This allows `graceful-fs` to evaluate `fs` source without access to internals. This is a temporary workaround that makes npm work. See: isaacs/node-graceful-fs#41Fixes: nodejs#1898 PR-URL: nodejs#1903 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
bnoordhuis
commented
Jun 5, 2015
@indutny Is this PR still relevant? I remember when I last reviewed it I didn't really get the point. Perhaps some TLS regression tests would help? |
indutny
commented
Jun 5, 2015
Yes, it is relevant. I will work on regression test for this. |
PR-URL: nodejs#1905 Refs: nodejs#1791 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
On case insensitive platforms, the rule was catching the debug module under npm and eslint. See: nodejs#1899 (comment) PR-URL: nodejs#1908 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
os.homedir() calls libuv's uv_os_homedir() to retrieve the current user's home directory. PR-URL: nodejs#1791 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Rod Vagg <rod@vagg.org>
Wait for the `shutdown` request completion before emitting the `finish` event and destroying the socket. While this might not be that relevant in case of plain TCP sockets, the TLS implementation sends close-notify packet during shutdown request. Destroying socket whilst this write is in progress tends to cause ECONNRESET errors in our tests.
bd4daca to
f3503baCompareindutny
commented
Jun 6, 2015
Thinking about it, it looks like it is no longer needed. Thanks for raising the question, @bnoordhuis . |
Wait for the
shutdownrequest completion before emitting thefinishevent and destroying the socket. While this might not be that relevant
in case of plain TCP sockets, the TLS implementation sends close-notify
packet during shutdown request. Destroying socket whilst this write is
in progress tends to cause ECONNRESET errors in our tests.