• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-terracotta
  • lorban
  • Reporter: lorban
  • April 01, 2010
  • 0
  • Watchers: 0
  • May 21, 2010
  • April 01, 2010

Description

After EHC-670 got fixed, another exception showed up:

java.lang.NullPointerException at bitronix.tm.recovery.RecoveryHelper.recover(RecoveryHelper.java:83) at bitronix.tm.recovery.RecoveryHelper.recover(RecoveryHelper.java:45) at bitronix.tm.recovery.Recoverer.recover(Recoverer.java:205) at bitronix.tm.recovery.Recoverer.recoverAllResources(Recoverer.java:174) at bitronix.tm.recovery.Recoverer.run(Recoverer.java:113) at java.lang.Thread.run(Thread.java:619)

RecoveryHelper.java:83 corresponds to this line:

if (xid.getFormatId() != BitronixXid.FORMAT_ID) {

which indicates that the Xid array returned by EhcacheXAResourceImpl.recover() contains a null entry

Comments

Ludovic Orban 2010-04-01

Problem lies in tim-ehcache-2.0.0’s EhcacheXAStoreClusteredImpl.getPreparedXids() implementation:

public Xid[] getPreparedXids() { Collection xidSet = prepareXids.keySet(); int size = xidSet.size(); return xidSet.toArray(new XidClustered[size]); \}

Since prepareXids.keySet() returns a reference to the live set, by the time the XidClustered array is built its size could very well change which could leave null entries in the created array.

Ludovic Orban 2010-04-01

new non-blocking implementation which should be thread safe:

public Xid[] getPreparedXids() { Collection xidSet = prepareXids.keySet(); Object[] preparedXids = xidSet.toArray();

 XidClustered[] xidArray = new XidClustered[preparedXids.length];
 System.arraycopy(preparedXids, 0, xidArray, 0, preparedXids.length);
 return xidArray;    \}

Ludovic Orban 2010-04-01

fixed in trunk and tc-3.2 branch.

Himadri Singh 2010-04-28

Verified by running h2lcperf test