Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-2173

NPE when using XA enlistment without recovery

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

      When using xa enlistment (transaction/useSynchronization=false, default), and recovery is disabled (transaction/recovery/enabled=false, default) the transaction manager might invoke recovery related methods such as XAResource.forget() in certain situations.
      E.g. the JBossTM invokes "forget", if during, XAResource.commit(xid, true) (second param means 1PC=true) an exception is thrown. (I expect an XAResource.rollback to be invoked in between the failed commit and forget).
      Here is such a stack trace:

      2012-07-25 14:13:42,821 WARN (testng-CheckRemoteLockAcquiredOnlyOnceDistTest [org.infinispan.transaction.xa.TransactionXaAdapter] Exception removing recovery information:java.lang.NullPointerException
      at org.infinispan.transaction.xa.TransactionXaAdapter.forget(TransactionXaAdapter.java:159)
      at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.forget(XAResourceRecord.java:759)
      at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:691)
      at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2285)
      at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1468)
      at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
      at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
      at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
      at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
      at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenOperation(CheckRemoteLockAcquiredOnlyOnceTest.java:157)
      at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenPutAll(CheckRemoteLockAcquiredOnlyOnceTest.java:100)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:601)
      at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
      at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
      at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
      at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
      at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
      at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
      at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
      at org.testng.TestRunner.privateRun(TestRunner.java:749)
      at org.testng.TestRunner.run(TestRunner.java:600)
      at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
      at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
      at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
      at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
      at java.lang.Thread.run(Thread.java:722)

      As we do allow xa enlistment without recovery enabled this NPE shouldn't be shown to the user.
      Instead an warning should be logged stating that XA enlistment is configured without recovery, but recovery might be needed in certain situations.

            [ISPN-2173] NPE when using XA enlistment without recovery

            Finally, I decided to log that as a trace.

            Adrian Nistor (Inactive) added a comment - Finally, I decided to log that as a trace.

            The fix seems trivial, forget() should return immediately if recoveryEnabled is false. I would not log any message about recovery being disabled.

            Adrian Nistor (Inactive) added a comment - The fix seems trivial, forget() should return immediately if recoveryEnabled is false. I would not log any message about recovery being disabled.

            I would'nt even log a warning. Maybe just an INFO message.

            Manik Surtani (Inactive) added a comment - I would'nt even log a warning. Maybe just an INFO message.

              anistor Adrian Nistor (Inactive)
              mircea.markus Mircea Markus (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: