[ https://jira.jboss.org/jira/browse/JBSEAM-4487?page=com.atlassian.jira.pl... ] dave atkins updated JBSEAM-4487: -------------------------------- Description: 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. 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. The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises. 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 add a ThreadLocal to Identity.create that counts recursive calls. If more then two recursive calls are detected an IllegalStateException is thrown. This isn't definitely isn't a permanent solution, but stops our server creating 100,000 sessions. was: 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. 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. The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises. 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 add a ThreadLocal to Identity.create that counts recursive calls. If more then two recursive calls are detected an IllegalStateException is thrown. This isn't 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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-4487?page=com.atlassian.jira.pl... ] dave atkins updated JBSEAM-4487: -------------------------------- Description: 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. 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. The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application using identity.logout in another request before the search has completed, the problem arises. 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. was: 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. 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. The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises. 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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-4487?page=com.atlassian.jira.pl... ] David Atkins updated JBSEAM-4487: --------------------------------- Description: 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. Recreating the problem is a bit hit and miss. The following worked on a windows server - In our application we have a search page that can take quite a while to complete a request. If we log out of the application using identity.logout in another request before the search has completed, the problem arises. On linux this doesn't cause the problem to occur, yet the original stack trace was from a linux server. 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. was: 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. The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application using identity.logout in another request before the search has completed, the problem arises. 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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-4487?page=com.atlassian.jira.pl... ] David Atkins updated JBSEAM-4487: --------------------------------- Description: 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. was: 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. To recreate in Windows: In our application we have a search page that can take quite a while to complete a request. If we log out of the application using identity.logout in another request before the search has completed, the problem arises. 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, maybe due to the 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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugi... ] Daniel Neumegen commented on JBSEAM-4487: ----------------------------------------- Did you ever find a fix for this? We are currently experiencing this error on and off and haven't been able to fix it. -- 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

[ https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugi... ] 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. -- 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

[ https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugi... ] dave atkins commented on JBSEAM-4487: ------------------------------------- Daniel, I don't believe we ever resolved this (i'm with a new company now so can't check the code). I believe we stuck with the ThreadLocal work-around detailed in the post. -- 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

[ https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugi... ] Daniel Neumegen commented on JBSEAM-4487: ----------------------------------------- Funnily enough Mark actually sits two seats away from me (he directed me here originally), but we are using Glassfish 2.1 for our app, not weblogic. Dave, if you can remember anything about how you implemented the ThreadLocal solution that would be a great help. I'm still a bit new and haven't had any luck trying to implement the same thing. You can get me at dann.dev(a)gmail.com -- 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

[ https://issues.jboss.org/browse/JBSEAM-4487?page=com.atlassian.jira.plugi... ] Daniel Neumegen commented on JBSEAM-4487: ----------------------------------------- Hi Ruth, Thanks so much for the above code snippet, initial testing has shown it does mitigate the issue and stop the explosion of sessions! Thanks to Dave as well! As an addition, the class should still bypass interceptors (have @BypassInterceptors), who ever had worked on it before had remove it for some reason, and without it Seam still manages to create the sessions before the above can kick in. -- 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