[
https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715480#comment-12715480
]
Daniel Neumegen commented on JBSEAM-4487:
-----------------------------------------
Sorry Marek, I saw that the issue was still open, the question was directed at
the reporter, Dave Atkins, wondering if he ever found a fix for this as we are
experiencing the same issue.
> Concurrent requests; one invalidates the session, results in recursive loop
> of session creation
> -----------------------------------------------------------------------------------------------
>
> Key: JBSEAM-4487
> URL: https://issues.jboss.org/browse/JBSEAM-4487
> Project: Seam 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.1.GA, 2.1.2.CR1, 2.1.2.CR2, 2.1.2.GA, 2.2.0.CR1,
> 2.2.0.GA
> Environment: Jboss 4.2.2 with shipped Tomcat on Linux.
> Reporter: dave atkins
> Labels: session
>
> I noticed that we had an massive number of sessions on one of our tomcat
> nodes that hosts our modest Seam app. After some investigation I discovered
> this in the log
> 2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up:
> org.jboss.seam.web.session
> 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
> org.jboss.seam.security.identity
> 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
> org.jboss.seam.web.session
> 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
> org.jboss.seam.security.identity
> 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
> org.jboss.seam.web.session
> This is repeated for thousands of lines and tomcat reports we have over
> 100,000 sessions (far more than the 100s we normally have). After digging
> around the seam code I realised that if you have two concurrent requests and
> one invalidates the session before the other is finished, seam goes into an
> recursive loop of session creation (normally ended by stack overflow). Here's
> a stack trace showing two recursions.
> at org.jboss.seam.Component.newInstance(Component.java:2094)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
> at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
> at
> org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
> at
> org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
> at
> org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
> at
> org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
> at
> org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
> at
> org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
> at org.apache.catalina.connector.Request.getSession(Request.java:2075)
> at
> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
> at
> javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
> at
> org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
> at
> javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
> at
> javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
> at
> com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
> at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
> at
> org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
> at
> org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
> at org.jboss.seam.Component.getInstance(Component.java:1949)
> at org.jboss.seam.Component.getInstance(Component.java:1944)
> at org.jboss.seam.Component.getInstance(Component.java:1924)
> at org.jboss.seam.Component.getInstance(Component.java:1919)
> at org.jboss.seam.security.Identity.create(Identity.java:101)
> at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
> at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
> at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
> at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
> at org.jboss.seam.Component.newInstance(Component.java:2094)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
> at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
> at
> org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
> at
> org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
> at
> org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
> at
> org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
> at
> org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
> at
> org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
> at org.apache.catalina.connector.Request.getSession(Request.java:2075)
> at
> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
> at
> javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
> at
> org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
> at
> javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
> at
> javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
> at
> com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
> at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
> at
> org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
> at
> org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
> at org.jboss.seam.Component.getInstance(Component.java:1949)
> at org.jboss.seam.Component.getInstance(Component.java:1944)
> at org.jboss.seam.Component.getInstance(Component.java:1924)
> at org.jboss.seam.Component.getInstance(Component.java:1919)
> at org.jboss.seam.security.Identity.create(Identity.java:101)
> at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
> at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
> at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
> at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
> at org.jboss.seam.Component.newInstance(Component.java:2094)
> This problem is partially documented here -
> https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix
> didn't solve the root cause of the problem.
> The problem is caused by the SessionMap used by ServerConversationContext.
> Internally the session map uses HttpServletRequest.getSession(true) to
> retrieve the session, which creates a new session if the one defined on the
> HttpServletRequest is invalid or null. Unfortunately, when the new session is
> created session listeners are informed before the session has been set on the
> HttpServletRequest. Seam is one of these session listeners and creates a new
> Identity on session creation, which in turn accesses the SessionMap, still
> before the new Session has been set on the request. This leads to an infinite
> recursive loop.
> The SessionMap used is returned by externalContext.getSessionMap(). One
> solution could be to implement our own SessionMap that doesn't attempt to
> create a new session if the current session is invalid or null, although I've
> no idea how this would impact on other Seam code.
> In windows we can recreate the problem by having a button that calls
> #{session.invalidate}. Another more realistic way to recreate the problem is
> to have one tab performing a long running search and logging out using
> identity.logout in some other tab. When the search completes the error
> occurs.
> We've tried the above in Linux, but it doesn't recreate the problem. I
> suspect this is due to Windows and Linux returning the list of components in
> a different order, probably due to the underlying filesystem.
> We are using seam 2.1.1.GA. I've looked at the source code for the latest
> release and it appears that the problem will still occur due to use of
> SessionMap.
> Out current workaround is to override Identity.create and add a ThreadLocal
> that counts recursive calls. If more then two recursive calls are detected
> an IllegalStateException is thrown. This definitely isn't a permanent
> solution, but stops our server creating 100,000 sessions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
seam-issues mailing list
seam-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-issues
