-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|