-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sai,
On 7/11/2011 9:29 AM, Sai Pullabhotla wrote: > I took the threaddump and found that Tomcat's http service thread is > still blocked on the read from the client after we called the > forward method. At least, that's how I interpreted this, but below is > the particular thread's dump: > > "http-443-1" daemon prio=6 tid=0x000000004c20b000 nid=0x1720 > runnable [0x000000004f85f000] java.lang.Thread.State: RUNNABLE at > java.net.SocketInputStream.socketRead0(Native Method) at > java.net.SocketInputStream.read(SocketInputStream.java:129) at > com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293) > > at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789) > > - - locked <0x000000000b925a00> (a java.lang.Object) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746) > > at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) > - locked <0x000000000b925a10> (a > com.sun.net.ssl.internal.ssl.AppInputStream) at > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:735) > > at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:366) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:814) > > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > > at java.lang.Thread.run(Thread.java:619) If it's waiting on a request line, it looks like a dangling keep-alive request to me. On the other hand, a web browser that got a complete response should be showing the page, even if it's got a keep-alive connection still open with the server. > Firefox is the only browser where this delay happens. IE and Chrome > show the reply right away after forward is complete. That makes me > wonder if FF is not setting the content-length header correctly (it > is not using chunked as far as I can tell). Try using LiveHttpHeaders, FireBug, or any number of extensions that can show you the HTTP request and response headers. If you need mroe details, you could use a packet-sniffer like Wireshark to see the actual bytes including "chunked" details, etc. > The call to forward is the last thing the upload Servlet does, so > there are no more cleanups we do in the code. We are using the > commons-fileupload and making use of their streaming feature, so > we/commons-upload do not create any temp files. Good to know. Is there some other component in the mix, like a web server or other proxy? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bVU0ACgkQ9CaO5/Lv0PAo+QCeJYi21CzvZ9wjMTmjqTkAhWG1 h8QAoJB8UQjlWOFy5YutX6QopkxOP3Bq =8b5R -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
