[JBoss JIRA] (ISPN-2465) Rollback sent twice in certain situations
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2465:
--------------------------------
Fix Version/s: 6.0.0.Final
> Rollback sent twice in certain situations
> -----------------------------------------
>
> Key: ISPN-2465
> URL: https://issues.jboss.org/browse/ISPN-2465
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.8.Final, 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary.
--
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, 9 months
[JBoss JIRA] (ISPN-2367) ReadCommitted does not work in distributed mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2367?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-2367.
---------------------------------
Resolution: Rejected
in this scenario we offer more than read committed, we offer repeatable read so this shouldn't be a problem.
> ReadCommitted does not work in distributed mode
> -----------------------------------------------
>
> Key: ISPN-2367
> URL: https://issues.jboss.org/browse/ISPN-2367
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.7.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: ReadCommittedDistributedTest.java
>
>
> ReadCommitted isolation level doesn't work as expected in distributed mode:
> - tx1@Node1 reads (k1,v1) which is owned by Node2. At this point it keeps a cached copy of the entry locally
> - tx2@Node3 writes (k1,v2) and commits
> - tx1@Node1 reads k1 again and it gets the value "v1" - wrong!
--
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, 9 months
[JBoss JIRA] (ISPN-2538) Endless loop in TreeMap.remove at shutdown of query-enabled cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2538?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2538:
--------------------------------
Fix Version/s: 6.0.0.Final
> Endless loop in TreeMap.remove at shutdown of query-enabled cache
> -----------------------------------------------------------------
>
> Key: ISPN-2538
> URL: https://issues.jboss.org/browse/ISPN-2538
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta4
> Reporter: Marko Lukša
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
>
> {code}
> "MSC service thread 1-6" prio=6 tid=0x000000000d5b9000 nid=0x10a0 runnable [0x000000000e45e000]
> java.lang.Thread.State: RUNNABLE
> at java.util.TreeMap.fixAfterDeletion(TreeMap.java:2215)
> at java.util.TreeMap.deleteEntry(TreeMap.java:2173)
> at java.util.TreeMap.remove(TreeMap.java:600)
> at org.infinispan.query.impl.LifecycleManager.cacheStopped(LifecycleManager.java:181)
> at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:227)
> at org.infinispan.CacheImpl.stop(CacheImpl.java:540)
> at org.infinispan.CacheImpl.stop(CacheImpl.java:535)
> at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:348)
> at org.jboss.as.capedwarf.services.CacheLifecycleService.stop(CacheLifecycleService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
> 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)
> {code}
--
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, 9 months
[JBoss JIRA] (ISPN-2538) Endless loop in TreeMap.remove at shutdown of query-enabled cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2538?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2538:
--------------------------------
Assignee: William Burns (was: Dan Berindei)
> Endless loop in TreeMap.remove at shutdown of query-enabled cache
> -----------------------------------------------------------------
>
> Key: ISPN-2538
> URL: https://issues.jboss.org/browse/ISPN-2538
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta4
> Reporter: Marko Lukša
> Assignee: William Burns
> Fix For: 6.0.0.Final
>
>
> {code}
> "MSC service thread 1-6" prio=6 tid=0x000000000d5b9000 nid=0x10a0 runnable [0x000000000e45e000]
> java.lang.Thread.State: RUNNABLE
> at java.util.TreeMap.fixAfterDeletion(TreeMap.java:2215)
> at java.util.TreeMap.deleteEntry(TreeMap.java:2173)
> at java.util.TreeMap.remove(TreeMap.java:600)
> at org.infinispan.query.impl.LifecycleManager.cacheStopped(LifecycleManager.java:181)
> at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:227)
> at org.infinispan.CacheImpl.stop(CacheImpl.java:540)
> at org.infinispan.CacheImpl.stop(CacheImpl.java:535)
> at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:348)
> at org.jboss.as.capedwarf.services.CacheLifecycleService.stop(CacheLifecycleService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
> 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)
> {code}
--
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, 9 months
[JBoss JIRA] (ISPN-2367) ReadCommitted does not work in distributed mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2367?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2367:
--------------------------------
Fix Version/s: 6.0.0.Final
> ReadCommitted does not work in distributed mode
> -----------------------------------------------
>
> Key: ISPN-2367
> URL: https://issues.jboss.org/browse/ISPN-2367
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.7.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: ReadCommittedDistributedTest.java
>
>
> ReadCommitted isolation level doesn't work as expected in distributed mode:
> - tx1@Node1 reads (k1,v1) which is owned by Node2. At this point it keeps a cached copy of the entry locally
> - tx2@Node3 writes (k1,v2) and commits
> - tx1@Node1 reads k1 again and it gets the value "v1" - wrong!
--
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, 9 months
[JBoss JIRA] (ISPN-3289) PutForExternalRead should only write the value on the originator once
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3289?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3289:
--------------------------------
Fix Version/s: 6.0.0.Final
> PutForExternalRead should only write the value on the originator once
> ---------------------------------------------------------------------
>
> Key: ISPN-3289
> URL: https://issues.jboss.org/browse/ISPN-3289
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
>
> putForExternalRead behaves as an asynchronous, non-transactional write operation even in tx caches, and as such it uses lock delegation.
> Let's say we have a cluster with two nodes: [A, B], and a key k with owners(k) = [A, B].
> If B is the originator of a PFER(k, v) operation, the command is first executed locally on B, then it is invoked asynchronously on the primary owner A, and A invokes it asynchronously on B (because of the FORCE_ASNCHRONOUS flag).
> For regular non-tx write operations, the entry k=v is only written to the data container on B during the second invocation. For PFER, however, the entry is written twice: once during each execution.
> This causes random failures in {{PutForExternalRead*Test.testNoOpWhenKeyPresent}}, because the test assumes that the PFER finished once the entry was written once on each owner.
> Arguably the fact that the primary owner forwards the PFER command asynchronously is also a problem, because the put command will write the value on B without holding a lock on A, the primary owner.
--
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, 9 months
[JBoss JIRA] (ISPN-3289) PutForExternalRead should only write the value on the originator once
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3289?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3289:
--------------------------------
Assignee: William Burns (was: Dan Berindei)
> PutForExternalRead should only write the value on the originator once
> ---------------------------------------------------------------------
>
> Key: ISPN-3289
> URL: https://issues.jboss.org/browse/ISPN-3289
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: William Burns
> Fix For: 6.0.0.Final
>
>
> putForExternalRead behaves as an asynchronous, non-transactional write operation even in tx caches, and as such it uses lock delegation.
> Let's say we have a cluster with two nodes: [A, B], and a key k with owners(k) = [A, B].
> If B is the originator of a PFER(k, v) operation, the command is first executed locally on B, then it is invoked asynchronously on the primary owner A, and A invokes it asynchronously on B (because of the FORCE_ASNCHRONOUS flag).
> For regular non-tx write operations, the entry k=v is only written to the data container on B during the second invocation. For PFER, however, the entry is written twice: once during each execution.
> This causes random failures in {{PutForExternalRead*Test.testNoOpWhenKeyPresent}}, because the test assumes that the PFER finished once the entry was written once on each owner.
> Arguably the fact that the primary owner forwards the PFER command asynchronously is also a problem, because the put command will write the value on B without holding a lock on A, the primary owner.
--
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, 9 months
[JBoss JIRA] (ISPN-2661) Not a mapped entity (don't forget to add @Indexed) is thrown while using Clustered Query for DIST cache with InfinispanIndexManager enabled
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2661?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2661:
--------------------------------
Fix Version/s: 6.0.0.Final
> Not a mapped entity (don't forget to add @Indexed) is thrown while using Clustered Query for DIST cache with InfinispanIndexManager enabled
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2661
> URL: https://issues.jboss.org/browse/ISPN-2661
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Labels: clustered_queries, stable_embedded_query
> Fix For: 6.0.0.Final
>
> Attachments: ClusteredQueryMassIndexingTest.java, DistributedMassIndexingTest.java
>
>
> Running ClusteredQuery on Infinispan cache in distributed mode with enabled org.infinispan.query.indexmanager.InfinispanIndexManager as indexmanager and using infinispan as directory_provider, throws the following exception:
> {code}
> org.infinispan.CacheException: org.hibernate.search.SearchException: Not a mapped entity (don't forget to add @Indexed): class org.infinispan.query.queries.faceting.Car
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:189)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:206)
> at org.infinispan.query.clustered.ClusteredQueryInvoker.broadcast(ClusteredQueryInvoker.java:113)
> at org.infinispan.query.clustered.ClusteredCacheQueryImpl.getResultSize(ClusteredCacheQueryImpl.java:96)
> at org.infinispan.query.distributed.ClusteredQueryMassIndexingTest.verifyFindsCar(ClusteredQueryMassIndexingTest.java:26)
> at org.infinispan.query.distributed.DistributedMassIndexingTest.verifyFindsCar(DistributedMassIndexingTest.java:105)
> at org.infinispan.query.distributed.DistributedMassIndexingTest.testReindexing(DistributedMassIndexingTest.java:68)
> 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.hibernate.search.SearchException: Not a mapped entity (don't forget to add @Indexed): class org.infinispan.query.queries.faceting.Car
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:567)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:304)
> at org.infinispan.query.clustered.commandworkers.CQGetResultSize.perform(CQGetResultSize.java:40)
> at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:132)
> at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:127)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:101)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:122)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:86)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:245)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:218)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FC.up(FC.java:479)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> ... 3 more
> {code}
> You can find the test attached - ClusteredQueryMassIndexingTest.java which extends the DistributedMassIndexingTest (already from the testsuite). I've marked the verifyFindsCar() method there as protected for being able to override it. The cache configuration for the specified issue is:
> https://github.com/andyuk1986/infinispan/blob/master/query/src/test/resou...
--
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, 9 months
[JBoss JIRA] (ISPN-2598) NullPointerException in case of passing customized FetchOptions to ClusteredQuery iterator() method
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2598?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2598:
--------------------------------
Fix Version/s: 6.0.0.Final
> NullPointerException in case of passing customized FetchOptions to ClusteredQuery iterator() method
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-2598
> URL: https://issues.jboss.org/browse/ISPN-2598
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Labels: clustered_queries, stable_embedded_query
> Fix For: 6.0.0.Final
>
> Attachments: ClusteredQueryTest.java
>
>
> While running tests for query module, I've found the following thing. I'm not sure whether this is a bug, but the same flow for CacheQueryImpl works in different way rather than for ClusteredCacheQueryImpl.
> I'm running the following command on already created ClusteredQuery:
> {code}
> ResultIterator iterator = cacheQuery.iterator(new FetchOptions() {
> public FetchOptions fetchMode(FetchMode fetchMode) {
> return null;
> }
> });
> {code}
> This code throws NullPointerException, as the check of FetchMode is done in switch/case statement.
> The same code for CacheQuery throws IllegalArgumentException, as the check is done with if/else statement.
> Please find the test attached.
--
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, 9 months
[JBoss JIRA] (ISPN-2115) Relative path in rhq ant task cause build to fail
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2115?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2115:
--------------------------------
Fix Version/s: (was: 6.0.0.Alpha1)
> Relative path in rhq ant task cause build to fail
> -------------------------------------------------
>
> Key: ISPN-2115
> URL: https://issues.jboss.org/browse/ISPN-2115
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Reporter: Thomas Fromm
> Assignee: Tristan Tarrant
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> When the directory ../../ above the infinispan source dir is not writable,
> than build fails:
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (deploy) on project infinispan-rhq-plugin: An Ant BuildException has occured: Directory /usr/local/inubit/jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins creation was not successful for an unknown reason
> [ERROR] around Ant part ...<mkdir dir="../../..//jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins"/>... @ 4:116 in /usr/local/inubit/tf/infinispan/rhq-plugin/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (deploy) on project infinispan-rhq-plugin: An Ant BuildException has occured: Directory /usr/local/inubit/jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins creation was not successful for an unknown reason
> In current case the /usr/local/inubit/ is not writable for the user.
--
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, 9 months