On Fri, 2012-06-29 at 15:27 +0200, Jeff MAURY wrote: > No, > > it does not (yet) make sense because one piece of the puzzle is missing. > The Local socket is not a TCP socket, it is created from a path rather than > from an IP address. > So this socket is in no way linked to the browser, at least directly, and > the missing piece is what is the relation from this socket to the browser.
You're right, so the question is still open. In the mean time, I'm come across interesting google search results, among which the first one seems really interesting: Oracle Bug 6428742 ================== "Currently, on Windows, Runtime.exec is implemented by calling CreateProcess with the bInheritHandles argument set to TRUE, which causes open handles to not be closed if they are not explicitly set to be non-inherited. This is the underlying cause of many subtle bugs, such as 6347873: (so) Ports opened with ServerSocketChannel blocks when using Runtime.exec http://monaco.sfbay/detail.jsf?cr=6347873"; ==> Note the "if they are not explicitly set to be non-inherited" => this seems like a game changer, since our implicit assumption was that we would just look for code which would have accidentally set the handle to be inherited, not the other way around. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6428742 QT Project ========== "When using spawned processes, sockets opened by the client remain in CLOSE_WAIT state after closing the connection. Sockets on the remote side would be in FIN_WAIT_2 state and waiting for ACK. When the spawned (child) process is closed, then ACK is sent and sockets are finally moved to CLOSE state on both sides. This seems to be caused by the default handle inheritance on Windows by child processes." https://bugreports.qt-project.org/browse/QTBUG-4465 Zeromq2 project =============== "On Windows platform, in order to prevent child processes to inherit parent sockets, SetHandleInformation (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724935(v=vs.85).aspx) should be called on the socket handle. This patch comes out from discussion at: https://github.com/zeromq/clrzmq/issues/60"; https://github.com/zeromq/zeromq2-x/pull/51 and https://zeromq.jira.com/browse/LIBZMQ-366 I found way more interesting results, but I'll spare space and won't paste them all in this thread ( google search criteria : "windows inheriting socket handles" ) > > Jeff > > > On Fri, Jun 29, 2012 at 2:40 PM, Laurent Petit <lpe...@yseop.com> wrote: > > > Hello, > > > > On Fri, 2012-06-29 at 11:45 +0200, Jeff MAURY wrote: > > > > > That what I guessed but I don't understand everything. > > > The code you are referencing is related to NTPipes and not sockets. > > > > > > I'm not a C expert, but my bet is that the file name is misleading. > > > > Indeed, the > > > > con->sa.bInheritHandle = TRUE; > > > > statement appears in the definition driven by the following macro > > expansion: > > > > TCN_IMPLEMENT_CALL(jlong, Local, create)(TCN_STDARGS, jstring name, > > > > jlong pool) > > > > And when the macro call TCN_IMPLEMENT_CALL(jlong, Local, create) is > > preprocessed, it gives: > > > > > > JNIEXPORT RT JNICALL Java_org_apache_tomcat_jni_##Local##_##create > > > > , thus the bInheritHandle = TRUE statement is defined in the following > > function signature: > > > > JNIEXPORT RT JNICALL > > Java_org_apache_tomcat_jni_##Local##_##create(TCN_STDARGS, jstring name, > > jlong pool) > > > > which is a function called by JNDI, and as I guess, by class > > org.apache.tomcat.ini.Local, method create() : > > > > > > http://svn.apache.org/repos/asf/tomcat/native/branches/1.1.x/java/org/apache/tomcat/jni/Local.java > > > > And the javadoc for class Local is: "Local socket" > > And for methode create : > > /** > > > > * Create a socket. > > * @param path The address of the new socket. > > * @param cont The parent pool to use > > * @return The new socket that has been set up. > > */ > > > > > > It seems like the native code uses a pool, and my bet is that the pool > > is responsible for trying to reuse the socket. > > > > And something like this may happen: the socket handle, inherited by the > > child process, puts the socket in such a state that the pool either > > can't, either doesn't want to reuse it. > > > > And then what happens is that on the other side of the socket, the > > client continues to write HTTP requests, and nobody is listening. > > > > And then when the Tomcat's child process is killed, the socket is > > finally closed somehow, the client browser notices it and creates a new > > connection to the server and retries the HTTP request. > > > > > > Does that make sense ? > > > > > > > > > So I'm > > > not familiar with Tomcat Native implementation, but do you know the > > global > > > architecture ? > > > What I guessed is that the Tomcat native stuff created with the inherit > > > flag, but even if it does, I don't see why it should not work if the > > socket > > > is closed after a timeout. > > > > > > Regards > > > Jeff > > > > > > > > > > > > On Fri, Jun 29, 2012 at 11:22 AM, Laurent Petit <lpe...@yseop.com> > > wrote: > > > > > > > Hello Jeff, Konstantin & all, > > > > > > > > On Mon, 2012-06-25 at 20:52 +0200, verlag.preis...@t-online.de wrote: > > > > > Hello Jeff & all, > > > > > > > > > > > Von: Jeff MAURY <jeffma...@jeffmaury.com> > > > > > > Datum: Mon, 25 Jun 2012 18:46:02 +0200 > > > > > > > > > > > Konstantin, > > > > > > > > > > > > your explanations are very interesting but unclear to me: what do > > you > > > > > > call the inactivity timer ? When it is started ? After the request > > has > > > > > > been processed by the servlet ? In that case, I see no difference > > > > > > between a servlet that launch a process and another one. > > > > > > It seems to me that a process that is launched does not inhererits > > > > > > handles from its parent process but it's possible that under > > Windows, > > > > > > it's an option so it would be interesting to watch. > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > Sorry, I'm just a normal Tomcat user, and I don't know how exactly > > the > > > > APR connector and its Timeout works, so I am unable to answer that. > > > > > > > > > > > > > > > Howewer, I did some further observations: > > > > > > > > > > -When I perform a request to the servlet that opens wordpad.exe, the > > TCP > > > > connection from Tomcat does not close after the timeout - even when I > > kill > > > > the Tomcat process (java.exe), the TCP connection is still open. If I > > kill > > > > wordpad.exe, then finally the connection is closed/aborted. > > > > > -When I have 1 TCP connection open to Tomcat and the servlet starts > > the > > > > little C program, Task manager shows that it has 11 handles. > > > > > However, when I have 5 TCP connections open to Tomcat, and do the > > > > request on one of them, Task maanger shows that the C program has 15 > > > > handles - so four more handles when there are four more connections to > > > > Tomcat. All of that 5 TCP connections don't close until I kill that > > process. > > > > > > > > > > That seems to me to be an indication that socket handles could be > > > > inherited by the child processes that are startet by ProcessBuilder > > from > > > > tomcat. > > > > > > > > > > A msdn article mentions how to create a new process using > > > > CreateProcess(); it also mentions that socket handles can be inherited: > > > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724466.aspx > > > > > > > > > > However, as I don't have much knowledge about programming with > > WinAPIs, > > > > I don't know why those handles are inherited (the MSDN article mentions > > > > that a handle must be specified as inheritable when created, to allow a > > > > child process to inherit it). Maybe someone with more WinAPI/Tomcat > > Native > > > > knowledge can help here. > > > > > > > > > > > > I also had the vague intuition that this related to handles > > inheritence. > > > > Your recent tests & research tend to make this hypothesis even more > > > > appealing. > > > > > > > > I know nothing about tomcat-native implementation, but I was able to > > see > > > > that the bInheritHandle member is set to true here in tomcat native's C > > > > code: > > > > > > > > lpetit:~/tmp/tomcat-native $ grep "bInheritHandle" -R * > > > > native/os/win32/ntpipe.c: con->sa.bInheritHandle = TRUE; > > > > > > > > ( > > > > > > > > > > http://svn.apache.org/repos/asf/tomcat/native/branches/1.1.x/native/os/win32/ntpipe.c > > ) > > > > > > > > > > > > Jeff, > > > > > > > > What else could we do to help investigate / fix this issue ? > > > > > > > > > > > > Cheers, > > > > > > > > -- > > > > Laurent > > > > > > > > > > > > > > > > > > Regards, > > > > > Konstantin Preißer > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > > > > -- > > > > Laurent Petit > > > > > > > > Agence +33 (0)4 78 47 07 49 > > > > > > > > Email lpe...@yseop.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yseop apporte une réponse intelligente et individualisée à chacun de > > vos > > > > clients > > > > > > > > > > > > > > > > www.yseop.com > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > > > > > > > > > > > -- > > Laurent Petit > > > > Agence +33 (0)4 78 47 07 49 > > > > Email lpe...@yseop.com > > > > > > > > > > > > > > > > Yseop apporte une réponse intelligente et individualisée à chacun de vos > > clients > > > > > > > > www.yseop.com > > > > > > > > -- Laurent Petit Agence +33 (0)4 78 47 07 49 Email lpe...@yseop.com Yseop apporte une réponse intelligente et individualisée à chacun de vos clients www.yseop.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
