[ICE-6125] RuntimeException upon Session Expiry - ICEsoft JIRA Issue Tracker

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Won't Fix
Affects Version/s: 2.0-Beta2
Fix Version/s: 2.0.0
Component/s: Framework
Labels:
None
Environment:
ICEfaces 2

Description

Using a stock application like Auction upon session expiry the following RuntimeException occurs:

Oct 15, 2010 2:55:10 PM org.icefaces.impl.application.WindowScopeManager beforePhase
WARNING: Unable to set up WindowScope
java.lang.RuntimeException: Unknown window scope ID: f6gfb1qfco
    at org.icefaces.impl.application.WindowScopeManager.determineWindowID(WindowScopeManager.java:181)
    at org.icefaces.impl.application.WindowScopeManager.beforePhase(WindowScopeManager.java:127)
    at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:224)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:95)
    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    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:127)
    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:298)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:637)
org.icefaces.application.SessionExpiredException: Session has expired
    at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:103)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:115)
    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    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:127)
    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:298)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:637)

Issue Links

depends on

ICE-6189 Lazy Window Scope

Closed

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Ted Goddard added a comment - 15/Oct/10 10:39 AM

This appears to be caused by the recent change to dispose-window: it is now a standard JSF form post for increased compatibility; however, this means that the JSF lifecycle may be attempted after the session has expired. The dispose-window logic needs to be made aware of session validity and should exit immediately if a session is not available.

Show

Ted Goddard added a comment - 15/Oct/10 10:39 AM This appears to be caused by the recent change to dispose-window: it is now a standard JSF form post for increased compatibility; however, this means that the JSF lifecycle may be attempted after the session has expired. The dispose-window logic needs to be made aware of session validity and should exit immediately if a session is not available.

7 older comments

Hide

Permalink

Deryk Sinotte added a comment - 16/Nov/10 12:30 PM

So the printStackTrace in the Mojarra code is one issue.

Another is the inability to determine whether or not a session is "valid". In the code we use to morph a ViewExpiredException into a SessionExpiredException, we'd like to be able to determine if a session is currently valid. However, it seem that in a couple of our resource handlers, we are using this call

ExternalContext.getSessionMap()

which automatically creates a new session if one doesn't yet exist. Now trying to determine if this is the behaviour we want or not.

Show

Deryk Sinotte added a comment - 16/Nov/10 12:30 PM So the printStackTrace in the Mojarra code is one issue. Another is the inability to determine whether or not a session is "valid". In the code we use to morph a ViewExpiredException into a SessionExpiredException, we'd like to be able to determine if a session is currently valid. However, it seem that in a couple of our resource handlers, we are using this call ExternalContext.getSessionMap() which automatically creates a new session if one doesn't yet exist. Now trying to determine if this is the behaviour we want or not.

Hide

Permalink

Deryk Sinotte added a comment - 16/Nov/10 1:09 PM

There are a couple of places where we use the following call in our ResourceHandlers:

Map sessionMap = externalContext.getSessionMap();

WindowScopeManager is the main one (but also SessionTimeoutMonitor). This method, according to the JavaDoc, will automatically create a session of a valid one is not available. Because of this, we may be inadvertently creating sessions when we shouldn't be. For example, right after a session expires, the next request is going through our resource handlers and a new session is created immediately.

There is currently another JIRA (http://jira.icefaces.org/browse/ICE-6189) for looking at lazy instantiation of Window Scope. As part of this work, we should ensure that session creation is not done unless absolutely necessary. Once that is complete, we can revist the strategy for sending Session Expired messages to the client. It may be that we turn it off or make it configurable.

Show

Deryk Sinotte added a comment - 16/Nov/10 1:09 PM There are a couple of places where we use the following call in our ResourceHandlers: Map sessionMap = externalContext.getSessionMap(); WindowScopeManager is the main one (but also SessionTimeoutMonitor). This method, according to the JavaDoc, will automatically create a session of a valid one is not available. Because of this, we may be inadvertently creating sessions when we shouldn't be. For example, right after a session expires, the next request is going through our resource handlers and a new session is created immediately. There is currently another JIRA ( http://jira.icefaces.org/browse/ICE-6189 ) for looking at lazy instantiation of Window Scope. As part of this work, we should ensure that session creation is not done unless absolutely necessary. Once that is complete, we can revist the strategy for sending Session Expired messages to the client. It may be that we turn it off or make it configurable.

Hide

Permalink

Deryk Sinotte added a comment - 16/Nov/10 1:16 PM

For the spurious stack trace in the Mojarra class, I've opened a ticket in their system:

https://mojarra.dev.java.net/issues/show_bug.cgi?id=4

Show

Deryk Sinotte added a comment - 16/Nov/10 1:16 PM For the spurious stack trace in the Mojarra class, I've opened a ticket in their system: https://mojarra.dev.java.net/issues/show_bug.cgi?id=4

Hide

Permalink

Deryk Sinotte added a comment - 03/Dec/10 1:07 PM

Looks like the original case that I logged got lost in the transition to the new JIRA tracking system to I opened another ticket:

http://java.net/jira/browse/JAVASERVERFACES-1883.

Show

Deryk Sinotte added a comment - 03/Dec/10 1:07 PM Looks like the original case that I logged got lost in the transition to the new JIRA tracking system to I opened another ticket: http://java.net/jira/browse/JAVASERVERFACES-1883 .

Hide

Permalink

Ken Fyten added a comment - 20/Dec/10 6:49 PM

This is a Mojarra JSF bug.

Show

Ken Fyten added a comment - 20/Dec/10 6:49 PM This is a Mojarra JSF bug.

People

Assignee:

Deryk Sinotte

Reporter:

Jack Van Ooststroom

Votes:

0 Vote for this issue

Watchers:

1 Start watching this issue

Dates

Created:

15/Oct/10 10:34 AM

Updated:

03/Jan/11 4:19 PM

Resolved:

20/Dec/10 6:49 PM