Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-17774

Concurrent not synchronized access to hashmap in OgnlUtil class leads to infinite loop and high cpu

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 3.5
    • 2.9
    • None

      the xwork lib we use has a bug where in OgnlUtil class has not synchronization around accessing shared HashMap inside compile method. In par It may lead to a infinite loop in map.get() and therefore high cpu and the death of the system.

      This situation happened on eac on 19/11/2009.

            [CONFSERVER-17774] Concurrent not synchronized access to hashmap in OgnlUtil class leads to infinite loop and high cpu

            Don Willis added a comment -

            Resolving as fixed based on Stefan's comment above that the fixed xwork jar is included in 3.5

            Don Willis added a comment - Resolving as fixed based on Stefan's comment above that the fixed xwork jar is included in 3.5

            If using Confluence earlier than 3.5, please refer to this KB article: http://confluence.atlassian.com/display/CONFKB/Excessive+HashMap+with+Xwork+Causes+High+CPU+Load

            Roy Hartono [Atlassian] added a comment - If using Confluence earlier than 3.5, please refer to this KB article: http://confluence.atlassian.com/display/CONFKB/Excessive+HashMap+with+Xwork+Causes+High+CPU+Load

            Hi Husein,

            I've updated the fix for version to 3.5 as this was in fact updated for 3.5 and not 3.2-m4.

            Cheers,
            Stefan

            Stefan Saasen (Inactive) added a comment - Hi Husein, I've updated the fix for version to 3.5 as this was in fact updated for 3.5 and not 3.2-m4. Cheers, Stefan

            HuseinA added a comment -

            As far as I can see, xwork-1.0.3.2.jar comes bundled only with Confluence 3.5 onwards. Can we change the fix version to 3.5 instead to avoid any confusion to the affected users (3.2.x - 3.4.x)?

            HuseinA added a comment - As far as I can see, xwork-1.0.3.2.jar comes bundled only with Confluence 3.5 onwards. Can we change the fix version to 3.5 instead to avoid any confusion to the affected users (3.2.x - 3.4.x)?

            sure I'll check it

            Adrian Deccico [Atlassian] added a comment - sure I'll check it

            Matt Ryall added a comment -

            Is there any chance we could also get the source JAR deployed to the Maven repo? It would really help a lot with debugging in XWork-related code.

            Matt Ryall added a comment - Is there any chance we could also get the source JAR deployed to the Maven repo? It would really help a lot with debugging in XWork-related code.

            I just checked what the changes were between 1.0.3.1 and 1.0.3.2:

            Boils down to this:

            diff --git a/src/java/com/opensymphony/xwork/util/OgnlUtil.java b/src/java/com/opensymphony/xwork/util/OgnlUtil.java
            index 318889f..abb11ad 100644
            --- a/src/java/com/opensymphony/xwork/util/OgnlUtil.java
            +++ b/src/java/com/opensymphony/xwork/util/OgnlUtil.java
            @@ -21,6 +21,7 @@ import java.beans.PropertyDescriptor;
             import java.util.HashMap;
             import java.util.Iterator;
             import java.util.Map;
            +import java.util.concurrent.ConcurrentHashMap;
             
             
             /**
            @@ -33,7 +34,7 @@ public class OgnlUtil {
                 //~ Static fields/initializers /////////////////////////////////////////////
             
                 private static final Log log = LogFactory.getLog(OgnlUtil.class);
            -    private static HashMap expressions = new HashMap();
            +    private static Map expressions = new ConcurrentHashMap();
             
                 //~ Methods ////////////////////////////////////////////////////////////////
            

            compile looks like this and is the only place in the code that uses the expressions Map:

                public static Object compile(String expression) throws OgnlException {
                    Object o = expressions.get(expression);
            
                    if (o == null) {
                        o = Ognl.parseExpression(expression);
                        expressions.put(expression, o);
                    }
            
                    return o;
                }
            

            While using the ConcurrentHashMap might solve the original problem reported, the compile method is still susceptible to race conditions as the put if absent operation isn't atomic.

            Stefan Saasen (Inactive) added a comment - I just checked what the changes were between 1.0.3.1 and 1.0.3.2 : Boils down to this: diff --git a/src/java/com/opensymphony/xwork/util/OgnlUtil.java b/src/java/com/opensymphony/xwork/util/OgnlUtil.java index 318889f..abb11ad 100644 --- a/src/java/com/opensymphony/xwork/util/OgnlUtil.java +++ b/src/java/com/opensymphony/xwork/util/OgnlUtil.java @@ -21,6 +21,7 @@ import java.beans.PropertyDescriptor; import java.util.HashMap; import java.util.Iterator; import java.util.Map; + import java.util.concurrent.ConcurrentHashMap; /** @@ -33,7 +34,7 @@ public class OgnlUtil { //~ Static fields/initializers ///////////////////////////////////////////// private static final Log log = LogFactory.getLog(OgnlUtil.class); - private static HashMap expressions = new HashMap(); + private static Map expressions = new ConcurrentHashMap(); //~ Methods //////////////////////////////////////////////////////////////// compile looks like this and is the only place in the code that uses the expressions Map: public static Object compile( String expression) throws OgnlException { Object o = expressions.get(expression); if (o == null ) { o = Ognl.parseExpression(expression); expressions.put(expression, o); } return o; } While using the ConcurrentHashMap might solve the original problem reported, the compile method is still susceptible to race conditions as the put if absent operation isn't atomic.

            Hi, I just updated pom version (rev 143600)

            Adrian Deccico [Atlassian] added a comment - Hi, I just updated pom version (rev 143600)

            Hi, I already uploaded 1.0.3.2 to Atlassian 3rd party repo.

            Adrian Deccico [Atlassian] added a comment - Hi, I already uploaded 1.0.3.2 to Atlassian 3rd party repo.

            This isn't fixed and as far as I can tell it never has been. Confluence is currently (in 3.4.x) still on 1.0.3.1 of this library. 1.0.3.2 is still not deployed to a maven repo.

            Don Willis added a comment - This isn't fixed and as far as I can tell it never has been. Confluence is currently (in 3.4.x) still on 1.0.3.1 of this library. 1.0.3.2 is still not deployed to a maven repo.

              adeccico Adrian Deccico [Atlassian]
              akazatchkov Anatoli
              Affected customers:
              0 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: