[GLASSFISH-19508] Race condition due to unsychronized HashMap access in ConnectorObjectFactory.getObjectInstance Created: 09/Jan/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2, 3.1.2.2, 4.0_b70
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: pdudits Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
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.



 Comments   
Comment by Jagadish [ 25/Mar/13 ]

http://java.net/jira/browse/GLASSFISH-19746 will take care of this issue.
Marking this for 4.0.1 as we are past the timeline for 4.0

Comment by pdudits [ 26/Mar/13 ]

That's a pity, I submitted the OCA over two weeks ago, but it is still not processed. There was also no reply when I asked for status, or whether there is any issue with the submission last week. Does it usually take this long?

Generated at Thu Sep 03 09:56:14 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.