> Von: Laurent Petit <lpe...@yseop.com> > Datum: Mon, 25 Jun 2012 17:46:06 +0200 > Hello Jeff & al, > > Here it is, I've created a Git repository with the sources for the > webapp & the test (maven projects), and instructions in the README on > how to reproduce the issue. > > https://github.com/lpetit-yseop/apr-test > > Hope this will help you get started on reproducing the problem, > > Regards,
Hello, I also could reproduce the problem on WIndows 7 64 Bit with Java 1.7.0_05 (64-bit) and Tomcat 7.0.28, using TC Native 1.1.24. I also used a small connectionTimeout="200". What I can see is, that with a normal request (that doesn't start a new process), Tomcat processes the request, and after an inactivity timeout of 200 ms, the APR connector closes the TCP connection. When the browser makes another request, it does open a new connection for that request. However, when a request goes to a servlet that starts a new process, and the timeout of 200 ms occurs, the TCP connection is not closed - but Tomcat doesn't seem to read on it any more, so further requests sent on that TCP connection will never be processed. When the new process (wordpad.exe) is closed, the TCP connection will be aborted. Then, the browser probably establishes a new TCP connection and re-sends it request there, which is processed by Tomcat. Unfortunately, don't have any knowledge of programming native (C) programms using Windows APIs, so I can only make a guess: Could it be that some handles to files/sockets are inherited to the child process (wordpad.exe) when launched by Java's ProcessBuilder, which prevent the socket from being closed? E.g., when I launch a simple C app (which calls WaitForSingleObject(-1, 999999)) from the Windows explorer, I can see 7 handles in the taskmanger; whereas when it is launched by the servlet in tomcat, Task manager shows 11 handles - but as said, I don't know if that has something to do with the problem. Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org