[infinispan-issues] [JBoss JIRA] (ISPN-2727) Transactional put failed after master node with enabled InfinispanIndexManager is killed

[Galder Zamarreño (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751633#comment-12751633 ] 

Galder Zamarreño commented on ISPN-2727:
----------------------------------------

The problem might be different here. Sanne mentioned that it was surprised to see the main thread storing "write.lock|M|person" in the cache. This lock is created in https://gist.github.com/7cb72687216682dff758 and is stored as part of https://gist.github.com/e15bea81fde756d0a425. The key thing here is that the LuceneIndexLocking cache is configured in the same way as the indexed cache, so that means transactional, indexed...etc.

Looking around, it's unclear whether this cache should be allowed to be transactional or not if the indexed cache is transactional.

If the answer to this question is that the lock cache should be transactional if the indexed cache is, the next question is: is synchronization a valid option for the lock cache and/or the indexed cache?
                
> Transactional put failed after master node with enabled InfinispanIndexManager is killed 
> -----------------------------------------------------------------------------------------
>
>                 Key: ISPN-2727
>                 URL: https://issues.jboss.org/browse/ISPN-2727
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Querying
>            Reporter: Anna Manukyan
>            Assignee: Galder Zamarreño
>             Fix For: 5.2.0.Final
>
>         Attachments: MultiNodeDistributedTest.java, MultiNodeLocalTest.java, MultiNodeLocalTxTest.java, MultiNodeReplicatedTest.java, MultiNodeReplicatedTxTest.java
>
>
> I've added new test, which uses the following Infinispan configuration: REPL_SYNC clustering mode, with transaction enabled, as well as enabled indexing with InfinispanIndexManager.
> The test adds several nodes with the described configuration, adds entries to different nodes, and checks that the query for the entries returns the same result for all nodes. 
> Then master node is killed, and then again new data is inserted and checked on all nodes. (Similiar test to https://github.com/infinispan/infinispan/blob/master/query/src/test/java/org/infinispan/query/distributed/MultiNodeReplicatedTest.java but with enabled transaction).
> When the test tries to insert new entry to one of the caches, after the master node kill, the following exception appears:
> {code}
> testIndexingWorkDistribution(org.infinispan.query.distributed.MultiNodeReplicatedTxTest)  Time elapsed: 1.656 sec  <<< FAILURE!
> javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> 	at org.infinispan.query.distributed.MultiNodeDistributedTest.storeOn(MultiNodeDistributedTest.java:78)
> 	at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:102)
> 	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:80)
> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:767)
> 	at org.testng.TestRunner.run(TestRunner.java:617)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> 	at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> 	at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> 	at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 	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)
> Caused by: org.infinispan.CacheException: Could not prepare. 
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> 	... 24 more
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> 	at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
> 	... 29 more
> {code}
> You can find the test attached. The test which fails is MultiNodeReplicatedTxTest.java . The rest are the tests which are the parents and a bit modified compared to the version in infinispan repo.

--
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