January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2366) Allow getCache() to return before the node receives any state

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2366?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2366: -------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/1503, https://github.com/infinispan/infinispan/pull/1586 (was: https://github.com/infinispan/infinispan/pull/1503) Submitted new PR to change the name of the config option. > 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.Beta6, 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2366) Allow getCache() to return before the node receives any state

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2366?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2366: -------------------------------- Fix Version/s: 5.2.0.CR2 5.2.0.Final > 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.Beta6, 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2366) Allow getCache() to return before the node receives any state

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2366?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2366: ------------------------------------- This was fixed in 5.2.0.Beta6 but the name of the config option (waitForInitialStateTransferToComplete) is horrible. Reopening this just to rename it to 'awaitInitialTransfer'. > 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.Beta6 > > > 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2366) Allow getCache() to return before the node receives any state

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2366?page=com.atlassian.jira.plugin.... ] Adrian Nistor reopened ISPN-2366: --------------------------------- > 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.Beta6 > > > 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

1
0
0 / 0

[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 commented on ISPN-2728: ------------------------------------- Isn't this yet another reincarnation of the root cause of ISPN-2578 ? TX commands for same tx are not supposed to be executed in parallel. Mircea's PR for ISPN-2728 should solve that. > 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 > > {{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

1
0
0 / 0

[JBoss JIRA] (ISPN-2656) Support RemoteCache.keySet()

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2656?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2656: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.2.0.CR2 Resolution: Done > Support RemoteCache.keySet() > ---------------------------- > > Key: ISPN-2656 > URL: https://issues.jboss.org/browse/ISPN-2656 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Ray Tsang > Assignee: Ray Tsang > Labels: hotrod > Fix For: 5.2.0.CR2, 5.2.0.Final > > > RemoteCache doesn't support keySet() method. A workaround is to use getBulk(). However, getBulk() returns both keys and values, which would be impractical with large dataset. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2728) AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2728?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2728: ------------------------------ Affects Version/s: 5.2.0.CR1 > AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE > ------------------------------------------------------------ > > Key: ISPN-2728 > URL: https://issues.jboss.org/browse/ISPN-2728 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > > {{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

1
0
0 / 0

[JBoss JIRA] (ISPN-2728) AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2728?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2728: ------------------------------ Component/s: Locking and Concurrency Transactions > 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 > > {{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

1
0
0 / 0

[JBoss JIRA] (ISPN-2728) AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2728: --------------------------------- Summary: AbstractCacheTransaction.hasLockOrIsLockBackup may cause NPE Key: ISPN-2728 URL: https://issues.jboss.org/browse/ISPN-2728 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa Assignee: Mircea Markus {{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

1
0
0 / 0

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

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-2727?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-2727: -------------------------------- Attachment: MultiNodeLocalTest.java MultiNodeLocalTxTest.java > 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: Sanne Grinovero > 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/... 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

11 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013