[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2173:
--------------------------------
Fix Version/s: 5.2.7.Final
> 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.2.7.Final, 5.3.0.Beta1, 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
12 years, 10 months
[JBoss JIRA] (ISPN-3132) Remove Metadata.read() method
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3132?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3132:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
integrated, thanks Galder!
> Remove Metadata.read() method
> -----------------------------
>
> Key: ISPN-3132
> URL: https://issues.jboss.org/browse/ISPN-3132
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.CR1
>
>
> As I started writing the documentation for Metadata, I came to the same conclusion that Mircea did WRT Metadata.read() method. It does not really make sense. Better to have a helper method that where needed, applies version information. Keeps interface clean and the helper method is always available.
> I'm also moving Metadata and related metadata classes to org.infinispan.metadata package to avoid polluting root package.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3108) Server endpoint compatibility enhancements
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3108?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3108:
--------------------------------
Fix Version/s: 5.3.0.CR1
> Server endpoint compatibility enhancements
> ------------------------------------------
>
> Key: ISPN-3108
> URL: https://issues.jboss.org/browse/ISPN-3108
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> Several TODOs:
> - Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
> - -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
> - -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
> - figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
> - -MetadataMortalCacheValue should extend MortalCacheValue, check others- <- That should not be the case because MetadataMortalCacheValue has metadata (which contains lifespan), and extending MortalCacheValue would add lifespan too, as separate reference, so MetadataMortalCacheValue extending MortalCacheValue would add an extra field to the object without any real benefit.
> - EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
> - Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
> - The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
--
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
12 years, 10 months