[
https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715538#comment-12715538
]
Marek Novotny commented on JBSEAM-4487:
---------------------------------------
no problem, I think that Mark resolved that by upgrading his runtime to
Weblogic 10.3.1, which is very probably using fixed version of servlet
implementation as this is primary issue in servlet container implementation, I
believe.
> 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
