1 Reply Latest reply on Feb 14, 2007 6:19 AM by lowecg2004

    problem passivation thread: ConcurrentModificationException

    lowecg2004

      Every now and then I get the following message in my logs:

      2006-12-05 12:27:09,109 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying event context
      2006-12-05 12:27:09,109 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preDestroyContext.EVENT
      2006-12-05 12:27:09,109 DEBUG [org.jboss.seam.contexts.Contexts] destroying: org.jboss.seam.core.manager
      2006-12-05 12:27:09,109 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preDestroy.org.jboss.seam.core.manager
      2006-12-05 12:27:09,109 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.postDestroyContext.EVENT
      2006-12-05 12:27:09,109 DEBUG [org.jboss.seam.contexts.Lifecycle] <<< End call
      2006-12-05 12:27:09,109 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] Saving session state to: C:\bin\seam\jboss-4.0.5.GA\server\default\tmp\sessions\SessionTimeoutHandlerHome-evc97who-j\5c4o1d3r-qbr45g-evc97n34-1-evc9ht00-13.ser
      2006-12-05 12:27:09,249 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@15d925b, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@524a69{ url=null ,addedOrder=0}
      2006-12-05 12:27:09,249 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@15d925b, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@9336bd{ url=null ,addedOrder=0}
      2006-12-05 12:27:09,265 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] Passivation complete; id=5c4o1d3r-qbr45g-evc97n34-1-evc9ht00-13
      2006-12-05 12:27:09,265 ERROR [org.jboss.ejb3.cache.simple.SimpleStatefulCache] problem passivation thread
       java.util.ConcurrentModificationException
       at java.util.LinkedHashMap$LinkedHashIterator.remove(LinkedHashMap.java:356)
       at org.jboss.ejb3.cache.simple.SimpleStatefulCache$SessionTimeoutTask.run(SimpleStatefulCache.java:132)
      2006-12-05 12:31:17,104 DEBUG [org.jboss.resource.connectionmanager.IdleRemover] run: IdleRemover notifying pools, interval: 450000
      2006-12-05 12:38:47,100 DEBUG [org.jboss.resource.connectionmanager.IdleRemover] run: IdleRemover notifying pools, interval: 450000
      2006-12-05 12:41:50,052 DEBUG [org.jboss.seam.contexts.Lifecycle] End of session, destroying contexts
      2006-12-05 12:41:50,052 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying conversation contexts: []
      2006-12-05 12:41:50,052 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying session context


      I'm using Seam 1.1 CR2, CVS 04-12-2006.

      I haven't noticed any erratic behaviour in my application and as far as I can tell, this has just started to happen recently.

      Cheers,

      C.

        • 1. Re: problem passivation thread: ConcurrentModificationExcept
          lowecg2004

          Finally realised what was going on with this.

          I had a LoginAction:

          @Stateful
          @Scope(ScopeType.EVENT)
          public class LoginAction implements Login, Serializable
          {
           @Out
           SessionTimeoutHander sessionTimeoutHander;
          
           ...
          
           public String login() {
           ...
          
           sessionTimeoutHander = Component.getInstance("sessionTimeoutHander");
          
           ...
           }
          }


          If a user had made a successful login twice within the same HTTP session (e.g. login, hit back button, login again - surprisingly, this scenario shows up quite a lot in my access logs!), the call to getInstance() would introduce a duplicate object. When the SFSB destruction code ran, I got the ConcurrentModificationException.

          The solution was to handle the creation of the sessionTimeoutHandler using a regular @In(create=true) against sessionTimeoutHandler and remove the call to getInstance(). I was assuming that my code above was equivalent to @In(create=true), but clearly it is not.

          Although there was no apparent problem in my application, because of exception raised during the SFSB clean-up there may be a potential memory leak situation since EJB3 cannot successfully destroy objects. The exceptions were recurring which would suggest that the objects are being held onto which supports this theory.

          Hope this helps,

          Cheers,

          Chris.