May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3063) Data Inconsistency when Recovery + syncCommitPhase=false

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3063?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3063: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1815 > Data Inconsistency when Recovery + syncCommitPhase=false > -------------------------------------------------------- > > Key: ISPN-3063 > URL: https://issues.jboss.org/browse/ISPN-3063 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.5.Final, 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: recovery, transaction > > with syncCommitPhase=false, the CommitCommand is sent asynchronously. the TransactionCoordinator sends immediately the TxCompletionNotificationCommand that can be deliver first than the CommitCommand. The CommitCommand fails silently: > {code} > if (transaction == null) { > if (trace) log.tracef("Did not find a RemoteTransaction for %s", globalTx); > return invalidRemoteTxReturnValue(); > } > } > {code} > This bug affects the 5.3 and 5.2.5. I've made one test case to catch this bug: > 5.3 => https://github.com/pruivo/infinispan/blob/rec-async/core/src/test/java/or... > 5.2 => https://github.com/pruivo/infinispan/blob/rec-async-5.2/core/src/test/jav... > Note: this bug may happen if you use async communication (prepare in 1PC) > Note2: this may be related to https://issues.jboss.org/browse/ISPN-2719 > Possible solutions: > * do not allow to configure the cache with syncCommitPhase=false && recovery enabled; > * force syncCommitPhase=true when recovery is enabled; > * send the CommitCommand and the TxCompletionNotificationCommand as Regular Messages (they will be deliver in FIFO order) > Thanks to Diego Didona that spotted this bug. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3083) Recovery parser always enable it

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3083?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3083: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1815 > Recovery parser always enable it > -------------------------------- > > Key: ISPN-3083 > URL: https://issues.jboss.org/browse/ISPN-3083 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 5.3.0.Beta1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 5.3.0.Final > > > in TransactionConfigurationBuilder: > {code:java} > public RecoveryConfigurationBuilder recovery() { > recovery.enable(); > return recovery; > } > {code} > This will enable the Recovery in configurations like this: > {code:xml} > <namedCache name="noRecovery"> > <transaction (...) transactionMode="NON_TRANSACTIONAL"> > <recovery enabled="false" recoveryInfoCacheName="someName"/> > </transaction> > </namedCache> > {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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-863) Eviction based on JVM memory utilization

by Brad Davis (JIRA)

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Brad Davis edited comment on ISPN-863 at 5/10/13 11:00 AM: ----------------------------------------------------------- I would agree with Robert; I think the best solution is the Instrumentation solution. The Instrumentation solution seems much less expensive than serialization and reflection to me. Although, if you have a write behind cache enabled that is already serializing, I could see then trying to leverage the size assuming the write behind has APIs to do so. Reflection seems way too expensive. It also seems that this wouldn't really need to "kick into gear" unless the JVM heap size is running "low". Maybe consider making the eviction policy something that kicks in when memory begins to consume a configurable portion of the total heap. One idea is to have the cache heap size calculated as a background non-blocking thread, where the heap does not affect "puts" to the cache unless the heap is already running low. If the heap is running low, we switch to "agressive eviction" mode, which blocks writes to the cache until the point that the heap-to-available memory threshold clears. Just thinking out loud. Does anyone know if getObjectSize actually already transverses sub-objects? http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumenta... was (Author: bdavis): I would agree with Robert; I think the best solution is the Instrumentation solution. The Instrumentation solution seems much less expensive than serialization and reflection to me. Although, if you have a write behind cache enabled that is already serializing, I could see then trying to leverage the size assuming the write behind has APIs to do so. Reflection seems way too expensive. It also seems that this wouldn't really need to "kick into gear" unless the JVM heap size is running "low". Maybe consider making the eviction policy something that kicks in when the heap begins to consume a configurable portion of heap. One idea is to have the cache heap size calculated as a background non-blocking thread, where the heap does not affect "puts" to the cache unless the heap is already running low. If the heap is running low, we switch to "agressive eviction" mode, which blocks writes to the cache until the point that the heap-to-available memory threshold clears. Just thinking out loud. Does anyone know if getObjectSize actually already transverses sub-objects? http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumenta... > Eviction based on JVM memory utilization > ---------------------------------------- > > Key: ISPN-863 > URL: https://issues.jboss.org/browse/ISPN-863 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction > Affects Versions: 4.2.0.Final > Environment: N/A > Reporter: Dave Marion > Assignee: Manik Surtani > Labels: eviction, threshold > Fix For: 6.0.0.Final > > > Allow user to specify percentage threshold upon which eviction will kick in and begin evicting entries based on the specified strategy. This would allow user to create a cache that will attempt to keep as many entries in memory as possible without having to specify maxEntries. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-863) Eviction based on JVM memory utilization

by Brad Davis (JIRA)

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Brad Davis commented on ISPN-863: --------------------------------- I would agree with Robert; I think the best solution is the Instrumentation solution. The Instrumentation solution seems much less expensive than serialization and reflection to me. Although, if you have a write behind cache enabled that is already serializing, I could see then trying to leverage the size assuming the write behind has APIs to do so. Reflection seems way too expensive. It also seems that this wouldn't really need to "kick into gear" unless the JVM heap size is running "low". Maybe consider making the eviction policy something that kicks in when the heap begins to consume a configurable portion of heap. One idea is to have the cache heap size calculated as a background non-blocking thread, where the heap does not affect "puts" to the cache unless the heap is already running low. If the heap is running low, we switch to "agressive eviction" mode, which blocks writes to the cache until the point that the heap-to-available memory threshold clears. Just thinking out loud. Does anyone know if getObjectSize actually already transverses sub-objects? http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumenta... > Eviction based on JVM memory utilization > ---------------------------------------- > > Key: ISPN-863 > URL: https://issues.jboss.org/browse/ISPN-863 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction > Affects Versions: 4.2.0.Final > Environment: N/A > Reporter: Dave Marion > Assignee: Manik Surtani > Labels: eviction, threshold > Fix For: 6.0.0.Final > > > Allow user to specify percentage threshold upon which eviction will kick in and begin evicting entries based on the specified strategy. This would allow user to create a cache that will attempt to keep as many entries in memory as possible without having to specify maxEntries. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3091: -------------------------------- Fix Version/s: 5.3.0.Final > Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > The backups do not receive the command at all. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3091: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1814 > Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2 > > > The backups do not receive the command at all. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2640) Design security functionality in Infinispan

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2640?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2640: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Design security functionality in Infinispan > ------------------------------------------- > > Key: ISPN-2640 > URL: https://issues.jboss.org/browse/ISPN-2640 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 6.0.0.Final > > > This serves as a prerequisite for ISPN-143 which is to be implemented in 6.0. The task is about gathering the requirements, discussing them with the community and sum them up in a requirements document. OpenShift team should also be involved in defining the requirements for this. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3091: -------------------------------- Description: The backups do not receive the command at all. > Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2 > > > The backups do not receive the command at all. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Work on ISPN-3091 started by Adrian Nistor. > Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2 > > > The backups do not receive the command at all. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3091: ----------------------------------- Summary: Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) Key: ISPN-3091 URL: https://issues.jboss.org/browse/ISPN-3091 Project: Infinispan Issue Type: Bug Components: Core API, Distributed Cache Affects Versions: 5.2.5.Final Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 5.3.0.Beta2 -- 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, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013