A little more info on the
org.apache.catalina.session.StandardSession.ACTIVITY_CHECK system
property:
The last time I said that the above property is keeping the session
alive, I was only partially correct. The way it is working is -
session is kept alive for the duration of the upload. The response is
sent to the client indicating upload successful. However, the next
request made immediately (I click on a button soon after the large
upload) fails because the session is destroyed as soon as tomcat
receives the request. What I'm rather looking for is - to keep the
session alive for the duration of the timeout after a large upload. So
if my session timeout is 1 minute, it would be nice if I can make a
second request within a minute after a large upload which might have
taken 5 minutes.
I also tried the STRICT_COMPLIANCE system property and set it to true
to see if that makes any difference, but noticed the same behavior.
I then tried the programmatic approach as below:
Upload Servlet retrieves the current session timeout and caches it in
a local variable (of the service/dopost).
Changes the session timeout to 5 minutes from 30 seconds (original,
just for testing, not that we will ever use 30 seconds in production)
After upload finishes, and before forwarding to the JSP, the servlet
resets the timeout to cached timeout of 30 seconds.
This did not work either, the subsequent request (right after a large
upload which took a minute or two) fails with session timed out.
Any ideas on how to make this work?
Thanks.
Sai Pullabhotla
On Mon, Jul 11, 2011 at 8:29 AM, Sai Pullabhotla
<sai.pullabho...@jmethods.com> wrote:
> 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
