Session timeout during file upload

[frankyb]

Hi all,

I have a problem related to JSF/Seam and RichFaces: on my page, I use a rich:fileupload control in Flash mode allowing the user to upload quite large files (up to 2 GB and maybe above).
The rich:fileupload is bound to a listener method in my session-scoped backing bean via the fileUploadListener attribute.

Everything works fine if the uploaded files are rather small. As soon as uploading takes a mentionable amount of time (some hours,as I said before, the file may be large), it breaks down when the upload is finished (when the progressbar of rich:fileupload has reached its maximum). The exception is:

30.04.2009 17:11:25 com.sun.faces.lifecycle.LifecycleImpl phase
WARNUNG: executePhase(RESTORE_VIEW 1,com.sun.faces.context.FacesContextImpl@4f5b6d) threw exception
java.lang.NullPointerException
     at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:191)
     at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:266)
     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:132)
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290
)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
     at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
     at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
     at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
     at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:365)
     at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
     at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235
)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
     at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
     at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
     at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
     at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
     at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
     at java.lang.Thread.run(Thread.java:619)
30.04.2009 17:11:25 com.sun.faces.lifecycle.LifecycleImpl phase
WARNUNG: executePhase(RESTORE_VIEW 1,com.sun.faces.context.FacesContextImpl@1670b57) threw exception

java.lang.NullPointerException
     at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:191)
     at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:266)
     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:132)
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290
)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
     at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
     at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
     at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
     at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
     at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
     at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235
)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
     at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
     at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
     at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
     at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
     at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
     at java.lang.Thread.run(Thread.java:619)

I assume the problem is that the user's session has timed out when the upload is finished and the framework wants to invoke the upload listener method in the backing bean.

So the question is whether there is a way to keep the session alive during file upload. Or is it possible to use some of the magic of Seam's conversation model in this case (for example, start a long-running conversation on begin of upload)? Actually, I don't know how to achieve that. Maybe someone can give me a hint :)

Thanks in advance,
Frank

[gonorrhea]

are you using a LRC or not?  you may have to turn off the session timeout in the web.xml or server.xml (or equivalent config file for JBoss, etc.)

you should post this question on the RF forum...

[gonorrhea]

I'm not sure web apps in general are designed to handle these extreme use case scenarios.  Does it usually take hours to upload a file(s)?  If yes, how bout using ftp, etc.?

[frankyb]

Thank you for your ressponse. Yes, the upload can take some hours. I adjusted the session timeout in the web.xml and now it works :) (even if this is probably not the best solution because I assume keeping sessions for such a long time causes heavy load on the server)

[jamesjmp]

If you only need a long timeout for the page where you upload, I advise you to define that long timeout only for that page.
For instance, in your pages.xml file

<page view-id="/UploadView.xhtml" timeout="12000000"/>

But in web.xml you may have a shorter default conversation-timeout.
Remember that session timeout must be always longer than any conversation timeout, but at least this way default conversations timeout would not be so long!

[gonorrhea]

This is probably a better idea.

from SiA book:

The default timeout period of the conversation is stored in the built-in component named
manager. The timeout is specified in milliseconds. The following component configuration
overrides the default timeout of ten minutes, setting it instead to a period of
one hour:

<core:manager conversation-timeout="3600000"/>

You can customize this value by setting the timeout attribute on the <page> node in
the page descriptor. This lets you modify the timeout period per view ID, so you can
give the user more time to fill out a more complex form:

<page view-id="/coursewizard/holeData.xhtml" timeout="7200000"/>

I was not aware of the timeout attribute for page element. 

In this case, 3600000 ms = 1 hr; 7200000 ms = 2 hr.  There was no reference to what the session timeout for this example should be.  Hypothetically assuming that the page uploads can take greater than 2 hrs, then what do you set the session timeout to?

Also, I thought the conversation-timeout applies to background conversations only.  Is this true?

http://solutionsfit.com/blog/2007/12/13/explaining-the-conversation-timeout-setting-through-example/:

the conversation-timeout only affects background conversations. The foreground conversation will only timeout when the session times out. Foreground, background, what? The foreground conversation is the conversation that the user last interacted with. A background conversation is any other conversation in the user’s session.

also, assuming foreground/background conversations are referring to LRCs specifically.

[frankyb]

Thanks for this proposal, I've already read the blog post you mentioned, but did not spend a lot of time for testing.
However, it seems like the session is more mighty than the conversations, since the conversations are restricted by the lifetime of the session. As soon as the session times out, the conversations are killed, too, be them foreground or background. So setting a high conversation timeout has no effect without adjusting the session timeout, too.

[gonorrhea]

I really think setting an unusually high (great than 1 hr?) session timeout is generally bad practice and should be last resort.

How bout spawning an ansync process that calls an external component (outside your Seam app) that handles this.  The user will be notified via email once the upload is complete/successful.

The only problem is that you probably won't know that an upload will take hours to complete and how would you handle this in terms of UI with user, etc.?

You would probably have to assume that it will always take hours and send the email.

I think an async process may be your solution here.

what do you think?

[frankyb]

I totally agree with you that setting the session timeout that high is not a good solution.

The idea with the external process is good, too. I will think about it. Maybe I can handle the upload using a separate stateless bean.

[deanhiller2000]

I also thought conversation timeout was only for background conversation but ran into this bug today

http://seamframework.org/Community/ConversationTimeoutOf2MinutesMakesBadFailures

in 2.2.1.CR1

looks like it is for foreground in my case too....odd