ICEfaces
  1. ICEfaces
  2. ICE-9242

ConcurrentModificationException in 1.8.2 P06

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: EE-1.8.2.GA_P07
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      -
    • Assignee Priority:
      P2
    • Salesforce Case Reference:

      Description

      There appears to be an issue with context synchronization in 1.8.2 P06. The exception has no functional impact and is not easily reproduced. Here is the exception:

      2013-04-29 09:40:44,866 Session Monitor ERROR com.xxx.as.service.log4j.impl.Log4jConfigurator$UncaughtExceptionHandler.uncaughtException(Log4jConfigurator.java:253) - Detected uncaught exception in thread: Session Monitor

      java.util.ConcurrentModificationException
      at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
      at java.util.HashMap$KeyIterator.next(HashMap.java:845)
      at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.shutdown(SessionDispatcher.java:440)
      at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.shutdownIfExpired(SessionDispatcher.java:453)
      at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener$1.run(SessionDispatcher.java:326)

      2013-04-29 09:40:44,866 Session Monitor DEBUG com.xxx.messaging.bmc.oamp.SessionCleaner.sessionDestroyed(SessionCleaner.java:38) - sessionDestroyed ac162d775700-2293736884-1-2066-1-3520-1025511666: Mon Apr 29 09:40:44 CEST 2013

        Activity

        Hide
        Deryk Sinotte added a comment -

        Working on fixing the errors in two similar cases (this one and ICE-9275) as there is no test app and the user says they are hard to produce.

        It's difficult to even find a Jetty 6 download anymore but I found one here: http://olex.openlogic.com/packages/jetty/6.1.14#package_detail_tabs. We don't currently officially support Jetty 8 (which is mentioned in one of the SalesForce cases) but it would be good to know if that's what they require support for. The issue is that, as of Jetty 7 and up (currently at 9), the Jetty project is now handled by the Eclipse Foundation. They've re-packaged the classes (org.mortbay is now org.eclipse) which is why our Jetty Continuation code doesn't work anymore (it's looking for and using the incorrect classes).

        Without a test case or a way to generate the problem the best I could do was make an educated guess as to the solution. For both issues, I've taken the same approach - wrapping the collection and synchronizing access to the collection during iteration. That way there should be no alterations of the collection during iteration which should hopefully mitigate the issues related to what is likely multiple thread access.

                   
        Index: src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java
        ===================================================================
        --- src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java	(revision 36585)
        +++ src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java	(working copy)
        @@ -32,8 +32,6 @@
         
         package com.icesoft.faces.webapp.http.servlet;
         
        -import com.icesoft.faces.async.render.GroupAsyncRenderer;
        -import com.icesoft.faces.context.View;
         import com.icesoft.faces.context.ViewStatus;
         import com.icesoft.faces.env.Authorization;
         import com.icesoft.faces.webapp.http.common.Configuration;
        @@ -50,6 +48,7 @@
         import java.lang.ref.WeakReference;
         import java.util.ArrayList;
         import java.util.Collection;
        +import java.util.Collections;
         import java.util.Date;
         import java.util.HashMap;
         import java.util.HashSet;
        @@ -377,7 +376,7 @@
         
             public static class Monitor implements Externalizable {
                 private final String POSITIVE_SESSION_TIMEOUT = "positive_session_timeout";
        -        private Set contexts = new HashSet();
        +        private Set contexts = Collections.synchronizedSet(new HashSet());
                 private HttpSession session;
                 private long lastAccess;
                 private String id;
        @@ -435,10 +434,12 @@
         
                 public void shutdown() {
                     //notify all the contexts associated to this monitored session
        -            Iterator i = contexts.iterator();
        -            while (i.hasNext()) {
        -                ServletContext context = (ServletContext) i.next();
        -                notifySessionShutdown(session, context);
        +            synchronized (contexts){
        +                Iterator i = contexts.iterator();
        +                while (i.hasNext()) {
        +                    ServletContext context = (ServletContext) i.next();
        +                    notifySessionShutdown(session, context);
        +                }
                     }
                     try {
                         session.invalidate();
        
        
        Show
        Deryk Sinotte added a comment - Working on fixing the errors in two similar cases (this one and ICE-9275 ) as there is no test app and the user says they are hard to produce. It's difficult to even find a Jetty 6 download anymore but I found one here: http://olex.openlogic.com/packages/jetty/6.1.14#package_detail_tabs . We don't currently officially support Jetty 8 (which is mentioned in one of the SalesForce cases) but it would be good to know if that's what they require support for. The issue is that, as of Jetty 7 and up (currently at 9), the Jetty project is now handled by the Eclipse Foundation. They've re-packaged the classes (org.mortbay is now org.eclipse) which is why our Jetty Continuation code doesn't work anymore (it's looking for and using the incorrect classes). Without a test case or a way to generate the problem the best I could do was make an educated guess as to the solution. For both issues, I've taken the same approach - wrapping the collection and synchronizing access to the collection during iteration. That way there should be no alterations of the collection during iteration which should hopefully mitigate the issues related to what is likely multiple thread access. Index: src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java =================================================================== --- src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java (revision 36585) +++ src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java (working copy) @@ -32,8 +32,6 @@ package com.icesoft.faces.webapp.http.servlet; -import com.icesoft.faces.async.render.GroupAsyncRenderer; -import com.icesoft.faces.context.View; import com.icesoft.faces.context.ViewStatus; import com.icesoft.faces.env.Authorization; import com.icesoft.faces.webapp.http.common.Configuration; @@ -50,6 +48,7 @@ import java.lang.ref.WeakReference; import java.util.ArrayList; import java.util.Collection; +import java.util.Collections; import java.util.Date; import java.util.HashMap; import java.util.HashSet; @@ -377,7 +376,7 @@ public static class Monitor implements Externalizable { private final String POSITIVE_SESSION_TIMEOUT = "positive_session_timeout"; - private Set contexts = new HashSet(); + private Set contexts = Collections.synchronizedSet(new HashSet()); private HttpSession session; private long lastAccess; private String id; @@ -435,10 +434,12 @@ public void shutdown() { //notify all the contexts associated to this monitored session - Iterator i = contexts.iterator(); - while (i.hasNext()) { - ServletContext context = (ServletContext) i.next(); - notifySessionShutdown(session, context); + synchronized (contexts){ + Iterator i = contexts.iterator(); + while (i.hasNext()) { + ServletContext context = (ServletContext) i.next(); + notifySessionShutdown(session, context); + } } try { session.invalidate();
        Hide
        Deryk Sinotte added a comment -

        Change checked in as described. Resolving as fixed but the customer will need to test to see if it fixes their issue as we cannot reproduce it.

        Show
        Deryk Sinotte added a comment - Change checked in as described. Resolving as fixed but the customer will need to test to see if it fixes their issue as we cannot reproduce it.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Tyler Johnson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: