This repository has been archived by the owner. It is now read-only.

forked processes ends socket connection if the child takes too long to load #6203

Open
williamkapke opened this Issue Sep 10, 2013 · 6 comments

Comments

Projects
None yet
4 participants
@williamkapke
Member

williamkapke commented Sep 10, 2013

The problem:

A forked process ends connections when these 2 conditions exist in the child:

  1. The child process thread takes longer than ~2 seconds to start.
  2. The child makes a http request.

NOTES:

  • This is only happens to the sockets that are given to the child before the child is done loading.

    UPDATE: Further testing indicates a behavior where it will hangup the connection even after loading has completed.
  • I'm running node v0.10.18 and have not tried on any other versions (yet).
  • NODE_DEBUG="net http" didn't reveal anything helpful.
  • This is on OSX 10.7.5

As discussed in the google group this may only be an issue on OSX.

I put together a small gist to demonstrate:
https://gist.github.com/williamwicks/6477189

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Sep 11, 2013

Member

Confirmed, thanks. I suspect there is some faulty logic in lib/child_process.js that closes the file descriptor before the child receives it. If you rewrite your test case to send over res.socket._handle rather than res.socket, then everything works - apart from the fact that the parent process now leaks file descriptors like mad, of course.

Member

bnoordhuis commented Sep 11, 2013

Confirmed, thanks. I suspect there is some faulty logic in lib/child_process.js that closes the file descriptor before the child receives it. If you rewrite your test case to send over res.socket._handle rather than res.socket, then everything works - apart from the fact that the parent process now leaks file descriptors like mad, of course.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell May 28, 2015

Member

@williamkapke ... unable to verify if this is still an issue because the gist seems to have disappeared. Is this still an issue for you?

Member

jasnell commented May 28, 2015

@williamkapke ... unable to verify if this is still an issue because the gist seems to have disappeared. Is this still an issue for you?

@williamkapke

This comment has been minimized.

Show comment
Hide comment
@williamkapke

williamkapke May 28, 2015

Member

Sry. I had a the username changed. Here's it is updated:
https://gist.github.com/williamkapke/6477189

Member

williamkapke commented May 28, 2015

Sry. I had a the username changed. Here's it is updated:
https://gist.github.com/williamkapke/6477189

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jun 3, 2015

Member

Ok, I'm seeing the described behavior still on v0.12.3~pre and io.js

Member

jasnell commented Jun 3, 2015

Ok, I'm seeing the described behavior still on v0.12.3~pre and io.js

@williamkapke

This comment has been minimized.

Show comment
Hide comment
@williamkapke

williamkapke Jun 14, 2016

Member

This is a very old issue of mine! @jasnell do you think there is any reason to keep this open on this archive repo? I don't even know if this is still valid. :/

Member

williamkapke commented Jun 14, 2016

This is a very old issue of mine! @jasnell do you think there is any reason to keep this open on this archive repo? I don't even know if this is still valid. :/

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Jun 14, 2016

It looks like this is still an issue on master, although the output from the gist could be clearer :-)

cjihrig commented Jun 14, 2016

It looks like this is still an issue on master, although the output from the gist could be clearer :-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.