Thanks, Chris!
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)
As suggested I took the dump a few times while the browser is waiting,
and in all cases the http thread is blocked on the read. I took
another dump after the browser has received the response, and the
above mentioned thread is in wait state.
I then ran my test with a couple of other browsers and found the following:
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).
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.
I wonder if some one else out there can try this scenario and see if
they can reproduce this. If you would like to see the full thread
dumps, please let me know (they are not huge, only a few threads) if I
can post it to the forum.
Thanks.
Sai Pullabhotla
On Sun, Jul 10, 2011 at 9:27 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sai,
>
> On 7/9/2011 8:55 AM, Sai Pullabhotla wrote:
>> I added the system property
>> org.apache.catalina.session.StandardSession.ACTIVITY_CHECK and set
>> it to true, and it appears to be preventing the session timeout.
>
> Glad to see it's working out for you.
>
>> That's a good news. Some one told me that there might be some
>> performance issues, but I'm not sure how significant they are.
>
> It was I who mentioned potential performance degradation. If you aren't
> in a super-high-concurrency situation, I don't think you'll notice.
>
>> The call to forward from the Servlet finishes in no time. However,
>> it takes about minute by the time the browser renders this JSP. While
>> the browser is waiting for the reply, the session is getting
>> destroyed. My question is, what is taking so long after the request
>> is forwarded.
>
> Take a thread dump. Or, multiple thread dumps during this one-minute
> interval. They should tell the story.
>
>> The code snippet we use to forward the request is -
>>
>> request.getRequestDispatcher("/MyJSP.jsp").forward(request,
>> response);
>>
>> I've a debug line before this call and after this call, they both
>> get printed right one after the other with no delay, but the browser
>> does not get anything back for about a minute.
>
> This might be a keepalive timeout, or the JSP might not be flushing the
> buffer or something like that.
>
>> If I upload fairly small files, the browser gets the response back
>> almost right away. The delay in receiving the reply on large files
>> is not new (or not caused by the new additional system property).
>
> Does your code do anything after the forward() call above? If you have
> clean-up code that, say, deletes the temporary files, etc. it's possible
> that it is delaying the return from your servlet's service() method and
> so Tomcat isn't indicating to the client that the transaction is complete.
>
> You should put a log message just before your return (or just before the
> end of the method if you have no returns in there) and see when that
> gets printed. That will at least tell you if the delay is in your code
> or elsewhere.
>
>> Any ideas on what could be going on? Does Tomcat some how feeds (or
>> tries to) the whole multipart request (after it is consumed by the
>> Servlet) to the forwarded JSP?
>
> The multipart request is still available to the JSP (because you used a
> forward call) put it's already been parsed by the servlet so there
> shouldn't be anything else to read.
>
>> I doubt it because, I did not notice any temp files being created
>> where the request might have been cached. The memory usage was
>> pretty low during the whole process so the request is definitely not
>> cached in memory.
>
> Tomcat does not cache anything at all in these cases... everything will
> be done by your file-upload component. Time for more debugging. :)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEUEARECAAYFAk4ZtukACgkQ9CaO5/Lv0PA6SwCXVK1r4bnZ/+fOxb4udH8Av6xo
> /gCgoKf6Z0QDe1q/Ps8zSI3ERX/VIR8=
> =mU2x
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
