Re: Session timeout during large response via setContentStream
Re: Session timeout during large response via setContentStream
- Subject: Re: Session timeout during large response via setContentStream
- From: Helmut Tschemernjak <email@hidden>
- Date: Fri, 12 Dec 2003 09:13:03 +0100
- Organization: HELIOS Software GmbH
Hello,
the problem is the same for uploading very large files, the session
times out. The problem is that the session timeout will kill the
response for downloads or the request for uploads. (e.g. the streaming
download).
Our workaround (since yesterday) is to increase the session timeout for
down and uploads to 24 hours and turn it back to the default after the
last up/download is completed.
This solves it for now. I will think about an direct action for later.
In general it is an WO problem which gets hopefully solved at some point
in time.
Helmut
Pierre Frisch wrote:
Do you need the session after the download is finished? I would suggest
that you create a special Request Handler. Use the session to create the
download file, store the data somewhere and return a url to the user
that grab the data from the specialized request handler. You can build
the handler like a direct action that does not require a session. For
security you can make the url as "one use only". Include in the url a
key that you match with the data and that you only serve once.
Pierre
On Thursday, December 11, 2003, at 06:08 PM, Chuck Hill wrote:
It looks like a very sticky problem. Any suggestions?
One idea that occurred to me was to not worry about the session timing
out.
Let it time out. Perhaps even terminate it when the download is sent
off.
Provide the user with a link to log into a new session.
Similar to this would be to return a redirect to Direct Action that
created
a new session specifically for the download. Either way leave the user
with a session they can use in another browser window and use a different
session for the download (if it even needs one).
Chuck
At 05:59 PM 11/12/2003 -0800, Hsu wrote:
Using the WO streaming may not help; I believe that the response is
streamed back to the client after the session is checked in.
Karl
On Dec 11, 2003, at 11:34 AM, Chuck Hill wrote:
Now that I think this through again, I see that I was wrong. It will
be
the webserver, not the WO app, doing the streaming. Hence the session
will
have been checked in and will expire. One solution would be to
increase
the session timeout when the download starts as you have done. Another
solution is to look at streaming the download from WO. I recall that
David
Teran of www.cluster9.com had a framework to do this. I don't know if
that
would avoid the session timeout problem or not, but it is probably
worth a
look.
Chuck
At 09:29 AM 11/12/2003 +0100, Helmut Tschemernjak wrote:
Hello Chuck,
we just use a standard WOComponent for the response, we send
immediately
data back to the user and the download is starting with about
100Kb/sec
(DSL). The problem is that the download takes about 1.5 hours and
WebObjects is timing out the session while the response is still
sending
the content stream provided by the InputStream.
I believe our ZipDownload component returns, the HTTP IO is still
sending data and and the SessionTimeoutManager does not know about it.
I can change the timeout to 24 hours which has the problem that idle
sessions will not timeout within a reasonable time.
Are you manually checking the session in ? NO
Helmut Tschemernjak
HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Phone: +49-5131-709320
Fax: +49-5131-709325
Internet Mail: email@hidden
Internet Web: http://www.helios.de
--------------------------------------
public class ZipDownload extends WOComponent {
protected iWSFileStream zipfs;
protected Number saveTimeout = application().sessionTimeOut();
public ZipDownload(WOContext context) {
super(context);
}
public void appendToResponse( WOResponse aResponse, WOContext
aContext) {
byte[] b;
super.appendToResponse(aResponse, aContext);
aResponse.setHeader("bytes", "Accept-Ranges");
aResponse.setHeader("application/zip", "Content-Type");
aResponse.setHeader("attachment; filename=\"" +
"download.zip" +
"\"",
"Content-Disposition");
if (zipfs.fsize > 0)
aResponse.setHeader("" + zipfs.fsize, "Content-Length");
aResponse.setContentStream(zipfs.getInputStream(), 8192,
zipfs.fsize);
}
public void setFilestream(iWSFileStream fs) {
if (zipfs != null) {
zipfs.Close();
return;
}
zipfs = fs;
session().setTimeOut(24*3600);
}
}
Chuck Hill wrote:
Are you returning this content in the context of a WO
request-response
loop? It is not supposed to be possible for a session to expire
while it
is checked out of the session store. Are you manually checking the
session
in?
Chuck
At 07:17 PM 10/12/2003 +0100, Helmut Tschemernjak wrote:
Hello,
we have a very large response (e.g.: 600MB), data is provided via
aResponse.setContentStream. After the session timeout of 3600
seconds
the response gets terminated while it is still activate sending
about
100KBytes per second!
The WO 5.2.2 stack backtrace for the terminate is:
#0 Session.terminate()
#1 WOSession._terminateByTimeout() at WOSession.java:529
#2 WOSessionStore$_SessionTimeoutManager.run()
atWOSessionStore.java:127
#3 java.lang.Thread.run() at Thread.java:554
We use the default 3600 second session timeout value, we don't like
to
go to a larger value because we like to cleanup unused sessions.
Has somebody seen a similar problem?
Is there a way to update the sessions activity/access time?
best regards / mit freundlichen Gruessen,
Helmut Tschemernjak
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.