January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2483) State transfer issue with the transactions for which the originator has crashed

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2483?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2483: -------------------------------- Priority: Critical (was: Blocker) > State transfer issue with the transactions for which the originator has crashed > ------------------------------------------------------------------------------- > > Key: ISPN-2483 > URL: https://issues.jboss.org/browse/ISPN-2483 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Beta3 > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.0.Final > > > State transfer migrates and prepares the transactions for which the originator has left. On the receiving node, this results in the transaction being prepared and acquiring backup locks which are never released (unless manual intervention). > This should behave as follows: > - if there's no recovery enabled, the state producer should not send such transactions but drop them > - if recovery is enabled these transactions should be sent across. They shouldn't be prepared/acquire backup locks, but be placed in the recovery cache (see RecoveryManagerImpl.inDoubtTransactions) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2483) State transfer issue with the transactions for which the originator has crashed

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2483?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2483: -------------------------------- Fix Version/s: 5.2.0.Final (was: 5.2.0.CR2) > State transfer issue with the transactions for which the originator has crashed > ------------------------------------------------------------------------------- > > Key: ISPN-2483 > URL: https://issues.jboss.org/browse/ISPN-2483 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Beta3 > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.Final > > > State transfer migrates and prepares the transactions for which the originator has left. On the receiving node, this results in the transaction being prepared and acquiring backup locks which are never released (unless manual intervention). > This should behave as follows: > - if there's no recovery enabled, the state producer should not send such transactions but drop them > - if recovery is enabled these transactions should be sent across. They shouldn't be prepared/acquire backup locks, but be placed in the recovery cache (see RecoveryManagerImpl.inDoubtTransactions) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2730) Not possible to instanciate org.infinispan.cdi.InfinispanExtension during startup of appserver

by Michael Mellenthin (JIRA)

Michael Mellenthin created ISPN-2730: ---------------------------------------- Summary: 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2730) Not possible to instanciate org.infinispan.cdi.InfinispanExtension during startup of appserver

by Michael Mellenthin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2730?page=com.atlassian.jira.plugin.... ] Michael Mellenthin updated ISPN-2730: ------------------------------------- Description: 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. was: 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. > 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

12 years, 11 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: ------------------------------------- Right! Nice catch! > 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

12 years, 11 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 edited comment on ISPN-2728 at 1/18/13 9:51 AM: -------------------------------------------------------------- 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-2578 should solve that. was (Author: anistor): 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

12 years, 11 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 commented on ISPN-2728: ----------------------------------- Nope, because the command which calls the hasLock... method belongs to different transaction, which is just waiting until older transactions finish. > 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2420) Increment the topology id when a node leaves the cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2420?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2420: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1587 The pull request doesn't address the possible optimizations/clarifications that can be made now that all ConsistentHash updates increment the topology id. Perhaps we should keep this issue open. > Increment the topology id when a node leaves the cache > ------------------------------------------------------ > > Key: ISPN-2420 > URL: https://issues.jboss.org/browse/ISPN-2420 > Project: Infinispan > Issue Type: Feature Request > Components: State transfer > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > We currently increment the topology id only when we "rebalance" the consistent hash (i.e. we add new owners). This allows us to to do some optimizations after a leave, like not forwarding commands (because there are no new owners). > Unfortunately, it is not very intuitive, because it doesn't match how JGroups works, so it can cause bugs like ISPN-2417. > Additionally, it turns out there are many places where we care that a node left, so the code is more complex to handle this (e.g. TransactionTable.useStrictTopologyIdComparison()), or it is more slow for the common case when there is no leaver (e.g. LocalTransaction.getCommitNodes()). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2729) [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-2729: --------------------------------- Summary: [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew Key: ISPN-2729 URL: https://issues.jboss.org/browse/ISPN-2729 Project: Infinispan Issue Type: Bug Components: Core API, Fine-grained API, Locking and Concurrency Affects Versions: 5.2.0.CR1 Environment: Mac OSx 10.5, Java 1.6 sun-jdk, maven 3.0.4 Reporter: Pedro Ruivo Assignee: Mircea Markus Test case available in here [1] When a transaction commits, the write skew check performs the validation by casting the cache entry to a ClusteredRepeatableReadEntry. However, the entry is a DeltaAwareCacheEntry. This happens when you have operations over a map inside a transaction. The tests failing are: WriteSkewFineGrainedAtomicMapAPITest.testSizeOnCache() WriteSkewFineGrainedAtomicMapAPITest.testCreateMapInTx() [1]https://github.com/pruivo/infinispan/commits/t_atomic_map_issue -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2632: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1576, https://github.com/infinispan/infinispan/pull/1587 (was: https://github.com/infinispan/infinispan/pull/1576) Send the cache topology id to the client instead of the JGroups view id. After a rebalance, the cache topology id is incremented, so this ensures that the client's topology information is updated as well. To work properly with replicated caches, this change required always incrementing the cache topology id after a leave, even if without a rebalance (https://issues.jboss.org/browse/ISPN-2420). > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.CR2, 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- 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, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013