Environment condition: - noised ethernet connection (10Mbit/sec - real speed due to interference: 80Kbyte/sec) Problem: - tomcat-app stop to reply http request after some reply (3 / 5) Network analisys: - server connection-state presentes some cli->srv TCP connection in timing-out state (LAST_ACK / CLOSE_WAIT) - client has all connections in established/full-closed states Evidence: - some network close-connection packets have been lost. This condition hang tomcat-web-application
We need more information to reproduce this condition. I haven't been able to reproduce it, so I'm closing this issue for now. Any advice on setting this up would be good. Alternatively, feel free to bring up your situation on the tomcat-user and tomcat-dev mailing lists, and we can try to help there, as it's a better discussion forum than Bugzilla.
> We need more information to reproduce this condition. Please, can you inform be about whats info do you need? For now I can tell to you that: - the same web-app works perfectly from another PC which is connected to the same server without noised cable - when the web-app hangs the other web-apps already works (but not the same-one) I traced network traffic and I have noticed that, with the sever-side TCP/IP connection state at CLOSE_WAIT, Tomcat use this connection to try to send HTTP-reply-fragment to client.
Roberto, please could you provide us more detail about: - the version of Tomcat and jvm you are running - OS and hw platform - network config and appliances Your issue seems strongly related to Bug #28727
> - the version of Tomcat and jvm you are running java version "1.5.0_02" > - OS and hw platform Linux k900 2.6.8.1-10mdk #1 Wed Sep 8 17:00:52 CEST 2004 i686 AMD Athlon(tm) 64 unknown GNU/Linux (Mandrake 10.1) Processor: Athlon 64 3000+ RAM: 512MByte (kingmax) HD: 160Gbyte (maxtor) Lan card: realtek Motherboard: ASUS A8V > - network config and appliances A "classic" SOHO switch who has connected: - LINUX server (with tomcat) - a WinME client (on a short unnoised ethernet cable) - a WinXP client (on a long noised ethernet cable) If I use WinME my web-app works correctly. If I use WinXP (with a short cable) my web-app works correctly. If I use WinXP (with the long noised cable) my web-app hangs after 3 HTTP reqs Note: the hang is systematically reproduceable > Your issue seems strongly related to Bug #28727 I don't know
Hi, I have un update about my bug. I have thied to build a workaround. I have executed this command (on linux srv): redir --lport=8081 --cport=8080 This command listen on port 8081 and redir every single connection to port 8080 (tomcat). If I connect to 8081 from the noised client my web-app works perfectly without hang-up. "redir" isolating tomcat from the noised connections. In fact if I execute a "netstat -n" I can see pending connection from redir and client BUT I don't see pending connection between tomcat and redir. Note: "redir" is an internet downloadable utility [http://dag.wieers.com/packages/redir/] TIA Roberto Colmegna
If you cannot point out any defect inside Tomcat, then we'll have to assume this is caused by a bad configuration of your network stack. -> INVALID
This isn't plausibile: the same wrong behaviour appear with tomcat on WinXP in the same noised-network.
This is simply wasting time. Please do not reopen the report until you can point out a specific defect in Tomcat.
Reply to a private email: At the moment, I am certain that the socket is closed properly by Tomcat at the end of the processing of the connection (input is shutdown, and then the socket is closed). So this is done properly (if you can find a case where this is not done properly, you can report it), then there's no explanation for the problem. We are working to have Tomcat use APR for the network stack (also used as the network stack in Apache httpd 2.x, so hopefully it is really robust and reliable ;) ) instead of the JVM's network stack. We'll be recommending that as the "production" stack to use after testing, and this could address your issue (that has been reported quite a few times, I have to admit).
Hi Remy, I have executed some other test and I have discovered that if I force the client-side (ie the internet browser) to use ONLY HTTP 1.0 (and NOT use HTTP 1.1) the problem disappears at all! In my opinion this is the evidence that the problem isn't in network-stack (excluding both of OS or java.net.*) . Regards, Roberto Colmegna
Ok, I give up trying to close this report, but I won't look into it either.
Marked as invalid as requested from Remy via private email ... but this does not mean that the problem is solved!
in "conf/server.xml", in the node: <Connector port="8080" maxHttpHeaderSize="8192" ...> add the attribute connectionLinger="60000" seem to solve/alleviate the problem.