glassfish
  1. glassfish
  2. GLASSFISH-19508

Race condition due to unsychronized HashMap access in ConnectorObjectFactory.getObjectInstance

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2, 3.1.2.2, 4.0_b70
    • Fix Version/s: 4.1
    • Component/s: jca
    • Labels:
      None
    • Environment:

      JDK 1.7.0_05 64-bit, Windows Server 2008 R2, Glassfish 3.1.2

      Description

      Maps created in ConnectorRegistry.getResourceFactories are neither concurrent or synchronized. I am experiencing a race condition when ConnectorObjectFactory.getObjectInstance() concurrently invokes put on such map. The result is corruption of HashMap's hashtable and infinite loops in HashMap.get() or HashMap.put() bringing system's CPUs utilization to constant 100%.

      Even though this has been only reproduced on Glassfish 3.1.2, these classes did not change in 3.1.2.2 or 4.0, so the bug also applies to all the versions.

      Example stack trace:

      pool-30-thread-39013
        at java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (HashMap.java:391)
        at com.sun.enterprise.resource.naming.ConnectorObjectFactory.getObjectInstance(Ljava/lang/Object;Ljavax/naming/Name;Ljavax/naming/Context;Ljava/util/Hashtable;)Ljava/lang/Object; (ConnectorObjectFactory.java:188)
        at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; (SerialContext.java:580)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(Ljava/lang/String;I)Ljava/lang/Object; (SerialContext.java:514)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(Ljava/lang/String;)Ljava/lang/Object; (SerialContext.java:455)
        at javax.naming.InitialContext.lookup(Ljava/lang/String;)Ljava/lang/Object; (InitialContext.java:411)
        at javax.naming.InitialContext.lookup(Ljava/lang/String;)Ljava/lang/Object; (InitialContext.java:411)
        at org.glassfish.osgi.ee.resources.ResourceProxy.getActualObject()Ljava/lang/Object; (ResourceProxy.java:81)
        at org.glassfish.osgi.ee.resources.ResourceProxy.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; (ResourceProxy.java:69)
        at $Proxy416.getConnection()Ljava/sql/Connection; (Unknown Source)
        at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(Ljavax/sql/DataSource;)Ljava/sql/Connection; (DataSourceUtils.java:111)
        at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(Ljavax/sql/DataSource;)Ljava/sql/Connection; (DataSourceUtils.java:77)
        at org.springframework.jdbc.core.JdbcTemplate.execute(Lorg/springframework/jdbc/core/PreparedStatementCreator;Lorg/springframework/jdbc/core/PreparedStatementCallback;)Ljava/lang/Object; (JdbcTemplate.java:572)
        at org.springframework.jdbc.core.JdbcTemplate.update(Lorg/springframework/jdbc/core/PreparedStatementCreator;Lorg/springframework/jdbc/core/PreparedStatementSetter;)I (JdbcTemplate.java:811)
        at org.springframework.jdbc.core.JdbcTemplate.update(Ljava/lang/String;Lorg/springframework/jdbc/core/PreparedStatementSetter;)I (JdbcTemplate.java:867)
        at org.springframework.jdbc.core.JdbcTemplate.update(Ljava/lang/String;[Ljava/lang/Object;)I (JdbcTemplate.java:875)
        ...
      

      After one hour run, the system had almost 30 threads stuck in this stacktrace.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Jagadish
            Reporter:
            pdudits
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: