October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3402) Add JDBC Cache Store config to RHQ plugin

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3402?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3402: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Add JDBC Cache Store config to RHQ plugin > ----------------------------------------- > > Key: ISPN-3402 > URL: https://issues.jboss.org/browse/ISPN-3402 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Server > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Final > > > ISPN-3350 was added to enhance some of the RHQ endpoints to allow for better runtime configuration support. However ISPN-3290 is also concurrently changing cache stores. Some changes for ISPN-3290 were mentioned to be possibly changing how the JDBC cache stores are configured and as such this has been excluded from ISPN-3350 to not implement it twice. > This is just to add in the support JDBC cache stores as they are missing. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3420) L1 and early invalidation leaves inconsistent state for Tx Cache

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3420?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3420: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > L1 and early invalidation leaves inconsistent state for Tx Cache > ---------------------------------------------------------------- > > Key: ISPN-3420 > URL: https://issues.jboss.org/browse/ISPN-3420 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Transactions > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Final > > > This is a duplicate of ISPN-2965 but to add changes for Tx caches. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3421) State Transfer can leave keys on < numOwners nodes for transactional caches.

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3421?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3421: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > State Transfer can leave keys on < numOwners nodes for transactional caches. > ---------------------------------------------------------------------------- > > Key: ISPN-3421 > URL: https://issues.jboss.org/browse/ISPN-3421 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > There's a hole in state transfer mechanism that can occur when a node is leaving the cluster, but it was creating the entries and was only able to replicate the data to some of the nodes. > The problem occurs when the segment ownership of the node doesn't change after the rebalance. Since state transfer does not request state for keys in which it is already an owner, the cache could be left in a state where a key is resident < numOwners nodes. In addition, this could be any subset of the primary OR backup nodes. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3426) L1 inconsistency in tx caches when backup owner replies to remote get

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3426?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3426: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > L1 inconsistency in tx caches when backup owner replies to remote get > --------------------------------------------------------------------- > > Key: ISPN-3426 > URL: https://issues.jboss.org/browse/ISPN-3426 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha2 > Reporter: Pedro Ruivo > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > Consider the following scenario > {noformat}node1: performs a remote get > node2 (backup owner): receives and replies to the remote get with v1 > node1: receives the repli and store in L1_ key => v1 > node2 (backup owner): commits a new value (v2) for the key (i.e. processes a commit command) > node3 (primary owner): sends the invalidation (but not for node1 because it hasn't received the remote get yet) and commits a new value (v2) for the key (i.e. processes a commit command) > node3 (primary owner): replies to the remote get with v2 > node1: ignores the reply because it used the node2 reply > {noformat} > *conclustion*: node1 keeps the old value stored in L1. > Possible solutions described here: > [L1 consistency for transactional caches|http://markmail.org/thread/ckbihuj5ch7qtdzj] > Could also be interesting: > [Staggered get question|http://markmail.org/thread/qun2frj2u5a2hnj2] > and > [ISPN-825|https://issues.jboss.org/browse/ISPN-825] -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3534) Investigate performance regressions in Infinispan 6.0.0

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3534?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3534: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Investigate performance regressions in Infinispan 6.0.0 > ------------------------------------------------------- > > Key: ISPN-3534 > URL: https://issues.jboss.org/browse/ISPN-3534 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.3.0.Final, 6.0.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.0.0.Final > > > As per QE: > 30% performance regression in distributed, udp, tx, async library stress tests > 20% performance regression in distributed, udp, tx, sync library stress tests > 20% performance regression in memcached client stress tests > 50%+ performance regression in REST client stress > tests -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3522) Upgrade to c3p0 version 0.9.2.1

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3522?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3522: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Upgrade to c3p0 version 0.9.2.1 > ------------------------------- > > Key: ISPN-3522 > URL: https://issues.jboss.org/browse/ISPN-3522 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > We are currently using c3p0 version 0.9.1.2, which is the last version with the {{c3p0}) group id. We should upgrade to the latest stable version, 0.9.2.1: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.mchange%22%20AND%2... > AFAIK version 0.9.2.1 does not solve the concurrency issue in ISPN-3324, but it may solve other problems. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3524) Add RHQ support for registering protobuf descriptors

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3524?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3524: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Add RHQ support for registering protobuf descriptors > ---------------------------------------------------- > > Key: ISPN-3524 > URL: https://issues.jboss.org/browse/ISPN-3524 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: William Burns > Fix For: 6.0.0.Final > > > This is the RHQ counterpart of ISPN-3172. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3513) LevelDBStore.init called three times

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3513?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3513: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > LevelDBStore.init called three times > ------------------------------------ > > Key: ISPN-3513 > URL: https://issues.jboss.org/browse/ISPN-3513 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > PersistenceManagerImpl.createLoadersAndWriters > calls LevelDBStore.init three times unnecessarily. > Also note that LevelDBStore is both CacheWriter and CacheLoader and the logic of createLoadersAndWriters doesn't seem to take into account that these are not exclusive. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3512) Don't deserialize the cache loader entries needed by a remote node

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3512?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3512: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Don't deserialize the cache loader entries needed by a remote node > ------------------------------------------------------------------- > > Key: ISPN-3512 > URL: https://issues.jboss.org/browse/ISPN-3512 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3556: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > When LockControlCommand fails on an owner, the rollback command is not sent > --------------------------------------------------------------------------- > > Key: ISPN-3556 > URL: https://issues.jboss.org/browse/ISPN-3556 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners. > However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners. > This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after. -- 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, 6 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 October 2013