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: Chuck Hill <email@hidden>
- Date: Thu, 11 Dec 2003 11:34:06 -0800
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.