Hello, I found the correct code to look at: http://svn.apache.org/repos/asf/tomcat/native/branches/1.1.x/native/src/network.c It does not set the inherit flag but it is using the apr library that maybe set the flag under Windows. If this is the case and according to your references, it is likely the client will not receive the ack and this is a problem with APR and Runtime.exec
Jeff On Fri, Jun 29, 2012 at 4:38 PM, Laurent Petit <lpe...@yseop.com> wrote: > 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.preisser@t-online.dewrote: > > > > > > 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 > > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
