[JBoss JIRA] (ISPN-2549) Invalidation mode caches with pessimistic transactions results in stale remote locks
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2549?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2549:
--------------------------------
Summary: Invalidation mode caches with pessimistic transactions results in stale remote locks (was: Invalidation mode caches with pessimistic transactions may result in stale remote locks)
> Invalidation mode caches with pessimistic transactions results in stale remote locks
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2549
> URL: https://issues.jboss.org/browse/ISPN-2549
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.0.Beta4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Final
>
> Attachments: InvalidationModePessimisticLockingIssueTest.java
>
>
> An invalidation mode cluster with two nodes A and B. Node A is coordinator.
> Putting a key on node B results in a remote lock being acquired on A. But the lock on A is not released when the TX commits. Subsequent attempts to lock the key on A will fail with TimeoutException.
> The key aspects to reproduce this are:
> 1. pessimistic locking
> 2. the transaction starts on a node different than the coordinator
> This scenario does not involve any state transfer, so it should not be related to the already known issues with stale locks caused by state-transfer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2173:
-------------------------------------
Finally, I decided to log that as a trace.
> NPE when using XA enlistment without recovery
> ---------------------------------------------
>
> Key: ISPN-2173
> URL: https://issues.jboss.org/browse/ISPN-2173
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: jdg6
> Fix For: 5.3.0.Final
>
>
> 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:
> {quote}
> 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)
> {quote}
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2173:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1726
> NPE when using XA enlistment without recovery
> ---------------------------------------------
>
> Key: ISPN-2173
> URL: https://issues.jboss.org/browse/ISPN-2173
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: jdg6
> Fix For: 5.3.0.Final
>
>
> 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:
> {quote}
> 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)
> {quote}
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2549) Invalidation mode caches with pessimistic transactions may result in stale remote locks
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2549?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2549:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1726
> Invalidation mode caches with pessimistic transactions may result in stale remote locks
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-2549
> URL: https://issues.jboss.org/browse/ISPN-2549
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.0.Beta4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Final
>
> Attachments: InvalidationModePessimisticLockingIssueTest.java
>
>
> An invalidation mode cluster with two nodes A and B. Node A is coordinator.
> Putting a key on node B results in a remote lock being acquired on A. But the lock on A is not released when the TX commits. Subsequent attempts to lock the key on A will fail with TimeoutException.
> The key aspects to reproduce this are:
> 1. pessimistic locking
> 2. the transaction starts on a node different than the coordinator
> This scenario does not involve any state transfer, so it should not be related to the already known issues with stale locks caused by state-transfer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2932) Verify that preloading a read only index in a cache will never hit the cacheloader
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-2932:
-------------------------------------
Summary: Verify that preloading a read only index in a cache will never hit the cacheloader
Key: ISPN-2932
URL: https://issues.jboss.org/browse/ISPN-2932
Project: Infinispan
Issue Type: Task
Components: Lucene Directory
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 5.3.0.Alpha1, 5.3.0.Final
With a warm cache (with no eviction) we should never need to hit the CacheLoader again.
Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should)
I'm suspecting demand of null valued entries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-2173:
-----------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> NPE when using XA enlistment without recovery
> ---------------------------------------------
>
> Key: ISPN-2173
> URL: https://issues.jboss.org/browse/ISPN-2173
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: jdg6
> Fix For: 5.3.0.Final
>
>
> 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:
> {quote}
> 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)
> {quote}
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2931) async mode changes remove behaviour
by Sebastian Tusk (JIRA)
[ https://issues.jboss.org/browse/ISPN-2931?page=com.atlassian.jira.plugin.... ]
Sebastian Tusk updated ISPN-2931:
---------------------------------
Summary: async mode changes remove behaviour (was: async mode changes API behaviour)
> async mode changes remove behaviour
> -----------------------------------
>
> Key: ISPN-2931
> URL: https://issues.jboss.org/browse/ISPN-2931
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: Mircea Markus
>
> With a cache setup as clustering dist, 2 owners and async mode the Cache.remove API does not behave correctly. Cache.remove(key) should return the old value and Cache.remove(key, value) should return true if the entry was removed. Both methods only work correctly if invoked on the primary owner of the key. If invoked on another node remove(key) returns null every time and remove(key,value) returns false every time. The Infinispan documentation says that in async mode these operations should work as expected. https://docs.jboss.org/author/display/ISPN/Asynchronous+Options
> Complete cache config:
> <namedCache name="distributed">
> <!-- Used to register JMX statistics in any available MBean server -->
> <jmxStatistics enabled="true" />
>
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="true" timeout="20000" />
> <hash numOwners="2"/>
> <async/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
>
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="3600000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
> </namedCache>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2931) async mode changes API behaviour
by Sebastian Tusk (JIRA)
Sebastian Tusk created ISPN-2931:
------------------------------------
Summary: async mode changes API behaviour
Key: ISPN-2931
URL: https://issues.jboss.org/browse/ISPN-2931
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.2.1.Final
Reporter: Sebastian Tusk
Assignee: Mircea Markus
With a cache setup as clustering dist, 2 owners and async mode the Cache.remove API does not behave correctly. Cache.remove(key) should return the old value and Cache.remove(key, value) should return true if the entry was removed. Both methods only work correctly if invoked on the primary owner of the key. If invoked on another node remove(key) returns null every time and remove(key,value) returns false every time. The Infinispan documentation says that in async mode these operations should work as expected. https://docs.jboss.org/author/display/ISPN/Asynchronous+Options
Complete cache config:
<namedCache name="distributed">
<!-- Used to register JMX statistics in any available MBean server -->
<jmxStatistics enabled="true" />
<clustering mode="dist">
<stateTransfer fetchInMemoryState="true" timeout="20000" />
<hash numOwners="2"/>
<async/>
</clustering>
<locking isolationLevel="READ_COMMITTED"
lockAcquisitionTimeout="15000" useLockStriping="false" />
<eviction maxEntries="10000" strategy="LRU" />
<expiration maxIdle="3600000" wakeUpInterval="5000"/>
<storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
</namedCache>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2173:
-------------------------------------
The fix seems trivial, forget() should return immediately if recoveryEnabled is false. I would not log any message about recovery being disabled.
> NPE when using XA enlistment without recovery
> ---------------------------------------------
>
> Key: ISPN-2173
> URL: https://issues.jboss.org/browse/ISPN-2173
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Labels: jdg6
> Fix For: 5.3.0.Final
>
>
> 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:
> {quote}
> 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)
> {quote}
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months