[JBoss JIRA] (ISPN-2728) AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2728?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2728:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1584
> AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE
> ------------------------------------------------------------
>
> Key: ISPN-2728
> URL: https://issues.jboss.org/browse/ISPN-2728
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, Transactions
> Affects Versions: 5.2.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Fix For: 5.2.0.CR2
>
>
> {{AbstractCacheTransaction.hasLockOrIsLockBackup}} can be called from non-synchronized context (particularly from the {{AbstractTxLockingInterceptor}} when iterating through all transactions from older topology). If the transaction is committed in parallel, {{AbstractCacheTransaction.clearLockedKeys}} is called which nulls the volatile field {{lockedKeys}}.
> {code}
> lockedKeys != null && lockedKeys.contains(key)
> {code}
> Contains a race condition - lockedKey may be nulled between the checks.
> Similar with {{backupKeyLocks}} but these are never nulled.
--
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, 12 months
[JBoss JIRA] (ISPN-2728) AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2728?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2728:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated. Thanks!
> AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE
> ------------------------------------------------------------
>
> Key: ISPN-2728
> URL: https://issues.jboss.org/browse/ISPN-2728
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, Transactions
> Affects Versions: 5.2.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Fix For: 5.2.0.CR2
>
>
> {{AbstractCacheTransaction.hasLockOrIsLockBackup}} can be called from non-synchronized context (particularly from the {{AbstractTxLockingInterceptor}} when iterating through all transactions from older topology). If the transaction is committed in parallel, {{AbstractCacheTransaction.clearLockedKeys}} is called which nulls the volatile field {{lockedKeys}}.
> {code}
> lockedKeys != null && lockedKeys.contains(key)
> {code}
> Contains a race condition - lockedKey may be nulled between the checks.
> Similar with {{backupKeyLocks}} but these are never nulled.
--
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, 12 months
[JBoss JIRA] (ISPN-2578) Two PrepareCommands in parallel cause ConcurrentModificationException
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2578?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2578:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated. Thanks!
> Two PrepareCommands in parallel cause ConcurrentModificationException
> ---------------------------------------------------------------------
>
> Key: ISPN-2578
> URL: https://issues.jboss.org/browse/ISPN-2578
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Blocker
> Fix For: 5.2.0.CR2
>
>
> Situation:
> 1) Node A broadcasts PrepareCommand to nodes B, C
> 2) Node A leaves cluster, causing new topology to be installed
> 3) The command arrives to B and C, with lower topology than the current one
> 4) Both B and C forward the command to node D
> 5) D executes the two commands in parallel and finds out that A has left, therefore executing RollbackCommand
> In {{AbstractTxLockingInterceptor.visitRollbackCommand}} we call {{LockManagerImpl.unlockAll}} which iterates over the keys and unlocks them. As these two prepares aren't synchronized over the {{lockedKeys}} set, one may unlock and remove these keys while the other is iterating through them, causing {{ConcurrentModificationException}}.
--
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, 12 months
[JBoss JIRA] (ISPN-2366) Allow getCache() to return before the node receives any state
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2366?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2366:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: (was: 5.2.0.Beta6)
Resolution: Done
Rename integrated.
> Allow getCache() to return before the node receives any state
> -------------------------------------------------------------
>
> Key: ISPN-2366
> URL: https://issues.jboss.org/browse/ISPN-2366
> Project: Infinispan
> Issue Type: Task
> Components: State transfer
> Affects Versions: 5.2.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Adrian Nistor
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
>
> With NBST it's possible to use a cache without having any local state. We should allow getCache() to return as soon as the joiner has received a consistent hash (actually CacheTopology) from the coordinator.
> This is related to ISPN-1394 - joiners should be able to work even if rebalancing is blocked.
--
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, 12 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-2588.
--------------------------------
Resolution: Done
ISPN-2405 is fixed.
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
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, 12 months
[JBoss JIRA] (ISPN-2615) org.infinispan.lock.StaleLocksTransactionTest testNoModsRollback and testNoModsCommit randomly fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2615?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-2615.
--------------------------------
Resolution: Done
ISPN-2405 is fixed.
> org.infinispan.lock.StaleLocksTransactionTest testNoModsRollback and testNoModsCommit randomly fails
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-2615
> URL: https://issues.jboss.org/browse/ISPN-2615
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Labels: testsuite_stability
> Fix For: 5.2.0.Final
>
>
> The tests are randomly failing on different environments.
> You can find the failures here:
> {code}
> Error Message
> expected [true] but found [false]
> Stacktrace
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:142)
> at org.infinispan.test.AbstractCacheTest.assertNotLocked(AbstractCacheTest.java:139)
> at org.infinispan.lock.StaleLocksTransactionTest.doTest(StaleLocksTransactionTest.java:79)
> at org.infinispan.lock.StaleLocksTransactionTest.testNoModsRollback(StaleLocksTransactionTest.java:61)
> 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)
> {code}
> {code}
> Error Message
> expected [true] but found [false]
> Stacktrace
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:142)
> at org.infinispan.test.AbstractCacheTest.assertNotLocked(AbstractCacheTest.java:139)
> at org.infinispan.lock.StaleLocksTransactionTest.doTest(StaleLocksTransactionTest.java:79)
> at org.infinispan.lock.StaleLocksTransactionTest.testNoModsRollback(StaleLocksTransactionTest.java:61)
> 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)
> {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
11 years, 12 months
[JBoss JIRA] (ISPN-2728) AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2728?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2728:
--------------------------------
Fix Version/s: 5.2.0.CR2
> AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE
> ------------------------------------------------------------
>
> Key: ISPN-2728
> URL: https://issues.jboss.org/browse/ISPN-2728
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, Transactions
> Affects Versions: 5.2.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Fix For: 5.2.0.CR2
>
>
> {{AbstractCacheTransaction.hasLockOrIsLockBackup}} can be called from non-synchronized context (particularly from the {{AbstractTxLockingInterceptor}} when iterating through all transactions from older topology). If the transaction is committed in parallel, {{AbstractCacheTransaction.clearLockedKeys}} is called which nulls the volatile field {{lockedKeys}}.
> {code}
> lockedKeys != null && lockedKeys.contains(key)
> {code}
> Contains a race condition - lockedKey may be nulled between the checks.
> Similar with {{backupKeyLocks}} but these are never nulled.
--
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, 12 months
[JBoss JIRA] (ISPN-2730) Not possible to instanciate org.infinispan.cdi.InfinispanExtension during startup of appserver
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2730?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-2730:
---------------------------------------
Can you please provide more information regarding the JDK in use ?
> Not possible to instanciate org.infinispan.cdi.InfinispanExtension during startup of appserver
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2730
> URL: https://issues.jboss.org/browse/ISPN-2730
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.2.0.CR1
> Environment: tested in openEJB
> Reporter: Michael Mellenthin
> Assignee: Pete Muir
> Priority: Critical
>
> I have infinispan-cdi library in my appserver to be able to use JSR-107.
> During startup of application server it loads the InfinispanExtension because the service provider is declared in META-INF/services.
> During startup I get the exception
> {code}
> Caused by: java.util.ServiceConfigurationError: javax.enterprise.inject.spi.Extension: Provider org.infinispan.cdi.InfinispanExtension could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.infinispan.cdi.InfinispanExtension with modifiers ""
> at java.util.ServiceLoader.fail(ServiceLoader.java:207)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
> {code}
> The reason is that the InfinispanExtension only provides a package scoped constructor.
> For sure the documentation of java.util.ServiceLoader is not very clear here. It just says:
> *"The only requirement enforced by this facility is that provider classes must have a zero-argument constructor so that they can be instantiated during loading"*
> But the implementation fails if the constructor is not public. Hence, we need a public constructor for InfinispanExtension.
--
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, 12 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2588 stopped by Adrian Nistor.
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
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, 12 months