-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 7/11/2011 4:54 PM, André Warnier wrote:
> I think that you need to scroll back in this thread (to July 8), and
> re-read an answer which Charles provided to a previous question of
> mine.
>
> A partial answer resides in this property, whic
Sai Pullabhotla wrote:
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
I agree. At this point, I'm not so concerned about the Firefox issue.
I will start a separate thread on it later. I still would like to get
some help on keeping the session alive for the duration of the
configured timeout, after a response is sent for a large request. Any
ideas will be greatly appr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 7/11/2011 3:59 PM, André Warnier wrote:
> It seems like there are two quite different issues/discussions going
> on in this same thread, with the same subject line. It is a bit
> confusing, even if originally they relate to the same problem.
It seems like there are two quite different issues/discussions going on in this same
thread, with the same subject line.
It is a bit confusing, even if originally they relate to the same problem.
Would it not be better to split this ?
-
-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 be
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 respo
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=0x4c20b000 n
-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 y
e:
>> From: André Warnier [mailto:a...@ice-sa.com]
>> Subject: Re: Uploading large files and session timeout
>
>> The do this cleanly, the servlet would need to call
>> HttpSession.getMaxInactiveInterval() at the beginning,
>> to save the existing value, then cal
> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: Uploading large files and session timeout
> The do this cleanly, the servlet would need to call
> HttpSession.getMaxInactiveInterval() at the beginning,
> to save the existing value, then call
> HttpSession.setM
Caldarale, Charles R wrote:
From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
Subject: Re: Uploading large files and session timeout
As far as I know, the session's lastAccessTime gets updated on each
request from the client (by the container), and there is no public API
to u
> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
> Subject: Re: Uploading large files and session timeout
> As far as changing the session timeout from the servlet, I do not
> think it works well when multiple uploads are going simultaneously
> under one session,
o offer.
Sai Pullabhotla
On Fri, Jul 8, 2011 at 2:20 PM, Caldarale, Charles R
wrote:
>> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
>> Subject: Re: Uploading large files and session timeout
>
>> As far as I know, the session's lastAccessTime gets updated o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sai,
On 7/8/2011 10:25 AM, Sai Pullabhotla wrote:
> If the upload takes longer then the session timeout, the session gets
> invalidated right after the upload. Tis means no further requests are
> accepted unless the user logs back in. Is this the expe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 7/8/2011 3:20 PM, Caldarale, Charles R wrote:
>> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
>> Subject: Re: Uploading large files and session timeout
>
>> As far as I know, the session's last
> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
> Subject: Re: Uploading large files and session timeout
> As far as I know, the session's lastAccessTime gets updated on each
> request from the client (by the container), and there is no public API
> to update
So your images are being stored to a database. As blobs? That's a difference
between our apps: I store the images to a repository and keep a short record
of the in a database.
I can't advise you on Tomcat, but if the database is the bottleneck, a
workaround might be to write your images to tempora
Just to give more details...
The session timeout setting is stored in our application's database.
Admins can change the session timeout from the UI we provide. We did
this to make it easy for our customers to set the desired timeout
rather than telling them going into web.xml and updating the time
How large are the files in question, and how long until the timeout? My app
does *a lot* of file uploading (and downloading), and I have not run across
this in the years I've used Tomcat. That's been since v3, but maybe I've
just never hit that limit.
Also, are you using a library like the Apache
Sai Pullabhotla wrote:
We have an application that uploads files using a Servlet deployed in
Tomcat 6. While this works most of the times, occasionally we run into
issues uploading large files. If the upload takes longer then the
session timeout, the session gets invalidated right after the uploa
21 matches
Mail list logo
