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: Hsu <email@hidden>
- Date: Thu, 11 Dec 2003 17:59:51 -0800
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
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
_______________________________________________
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.
--
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.
--
best regards / mit freundlichen Gruessen,
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
--
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.
--
If we had a destiny, then so had he - and if this is ours, then that
was his - and if there are no explanations for us, then let there be
none for him
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
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.