August 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3419) Write Skew check must be performed only in the primary owner

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3419: --------------------------------- Summary: Write Skew check must be performed only in the primary owner Key: ISPN-3419 URL: https://issues.jboss.org/browse/ISPN-3419 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 6.0.0.Alpha2 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 6.0.0.Alpha3 The following case can create data inconsistency: A: txA reads k with version v1 and writes on k (say valueA) primary-owner of k: txA acquire lock on k, validates and return v2 (increment(v1)) non-primary-onwer of k: txA registers a backup lock, validates and returns v2 (increment(v1)) A: txA commits with version v2. primary-owner of k: applies txA //commit in the non-primary-owner is delayed B: txB remote reads k with version v2 and writes on k (say valueB) and prepare the transaction primary-owner of k: txB waits until the lock is relased. non-primary-onwer of k: txA registers a backup lock, validates and returns v2 (increment(v1), because it has not applied the txA) primary-owner of k: lock is release, txB is validated and it return v3 (increment(v2)) B collects all the response and merge them. However, the map.value() can return first the response from primary-owner (v3) and them the response from the non-primary-owner (v2). The result version map will be k=>v2. txB will update k with the same previous version and a different value. from here the data will become inconsistent. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3418) Threads which get parked in CHMv8 won't ever be unparked

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3418?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3418: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2014 > Threads which get parked in CHMv8 won't ever be unparked > -------------------------------------------------------- > > Key: ISPN-3418 > URL: https://issues.jboss.org/browse/ISPN-3418 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 6.0.0.Alpha2 > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Alpha3 > > > We need to backport this upstream fix: > http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011696.html -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3418) Threads which get parked in CHMv8 won't ever be unparked

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3418: ------------------------------------- Summary: Threads which get parked in CHMv8 won't ever be unparked Key: ISPN-3418 URL: https://issues.jboss.org/browse/ISPN-3418 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 6.0.0.Alpha2 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 6.0.0.Alpha3 We need to backport this upstream fix: http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011696.html -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3415) ISPN 5.1.6 download does not deliver org.infinispan.loaders.jdbc package

by Ben Cotton (JIRA)

[ https://issues.jboss.org/browse/ISPN-3415?page=com.atlassian.jira.plugin.... ] Ben Cotton commented on ISPN-3415: ---------------------------------- Sanne, This is fantastic help! The link you provided on the forum post is exactly what I need! :-) THANK YOU. -Ben > ISPN 5.1.6 download does not deliver org.infinispan.loaders.jdbc package > ------------------------------------------------------------------------ > > Key: ISPN-3415 > URL: https://issues.jboss.org/browse/ISPN-3415 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.6.FINAL > Reporter: Ben Cotton > Assignee: Mircea Markus > Fix For: 5.1.x > > > The Infinispan 5.1.6 API (see http://docs.jboss.org/infinispan/5.1/apidocs/) documents the org.infinispan.loaders.jdbc package. However the Infinispan 5.1.6 distribution (http://jboss.org/infinispan/downloads/confirmation.html?downloadURL=http%... ) does not include the package within infinispan-core.jar -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3415) ISPN 5.1.6 download does not deliver org.infinispan.loaders.jdbc package

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3415?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3415: --------------------------------------- Hi Ben, I'm not the CacheStore expert here but I'll ping someone of the appropriate team, in hope they can integrate the skinny pointers I can put there on the forums post. Glad to help if we can, we just won't do more 5.1 releases that's all, but technically if anyone needs or is willing to provide backport patches to the 5.1 branch we will apply them and we don't mind uploading new releases in that case. In other words yes you could open JIRA issues on 5.1 branches but without assigning them, or better assigning them to volunteers from your team. Glad to make role permissions changes in the JIRA configuration if needed. > ISPN 5.1.6 download does not deliver org.infinispan.loaders.jdbc package > ------------------------------------------------------------------------ > > Key: ISPN-3415 > URL: https://issues.jboss.org/browse/ISPN-3415 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.6.FINAL > Reporter: Ben Cotton > Assignee: Mircea Markus > Fix For: 5.1.x > > > The Infinispan 5.1.6 API (see http://docs.jboss.org/infinispan/5.1/apidocs/) documents the org.infinispan.loaders.jdbc package. However the Infinispan 5.1.6 distribution (http://jboss.org/infinispan/downloads/confirmation.html?downloadURL=http%... ) does not include the package within infinispan-core.jar -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3357) Insufficient owners with putIfAbsent during rebalance

by Takayoshi Kimura (JIRA)

[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ] Takayoshi Kimura commented on ISPN-3357: ---------------------------------------- Yes the "originator dies" scenario is acceptable. > Insufficient owners with putIfAbsent during rebalance > ----------------------------------------------------- > > Key: ISPN-3357 > URL: https://issues.jboss.org/browse/ISPN-3357 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Attachments: 7c29bccb.log, ISPN-3357-full-logs-leave.zip > > > Here is test scenario: > * DIST numOwners=2, start with 3 nodes cluster then join 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 20074 > * node2: 19888 > * node3: 20114 > * node4: 18885 > Total is 78961, 1039 entries are missing. No error on HotRod client side so 80000 entries should be there. > Let's take a look at example missing entry, hash(thread01key151) = 7c29bccb. > Current CH: owners(7c29bccb) are [node1, node2] > Pending CH: owners(7c29bccb) are [node1, node2, node4] > Balanced CH: owners(7c29bccb) are [node1, node4] > The events sequence is: > * hotrod -> node1 > * node1 -> node2, node4 > * node2 committed entry > * node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created > * node1 committed entry > * node2 invalidates the entry because it's no longer an owner > Result owners(7c29bccb) are only node1 and node4 is missing. This entry may be completely lost by further rebalances when node4 is donor for this segment. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2965) L1 and early invalidation leaves inconsistent state

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2965?page=com.atlassian.jira.plugin.... ] Work on ISPN-2965 started by William Burns. > L1 and early invalidation leaves inconsistent state > --------------------------------------------------- > > Key: ISPN-2965 > URL: https://issues.jboss.org/browse/ISPN-2965 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Transactions > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Labels: 5.2.x > Fix For: 6.0.0.Alpha3 > > > In a distributed transactional cache with L1 enabled I can observe the following. > Prepare cache by adding an entry with Cache.put( k, v1 ). > 1. Node B starts with adding a changed value. Cache.put( k, v2 ) > 2. Node B TxDistributionInterceptor.visitPrepareCommand flushL1Caches sends invalidations. > 3. Node A calls Cache.get( k ) retrieves v1 and stores this value in L1. > 4. Node B proceeds with transaction. > The result is that Node A answers subsequent Cache.get(k) with v1 and Node B answers with v2. > It seems the invalidation is either send to early or must be synchronized in some way with the transaction. > Cache config: > <namedCache name="entity"> > <jmxStatistics enabled="true" /> > <clustering mode="dist"> > <stateTransfer fetchInMemoryState="false" timeout="20000" /> > <async /> > <l1 enabled="true" /> > <hash numOwners="1"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" > lockAcquisitionTimeout="15000" useLockStriping="false" /> > <eviction maxEntries="10000" strategy="LRU" /> > <expiration maxIdle="100000" wakeUpInterval="5000"/> > <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" /> > <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/> > </namedCache> -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2965) L1 and early invalidation leaves inconsistent state

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2965?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2965: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2012 > L1 and early invalidation leaves inconsistent state > --------------------------------------------------- > > Key: ISPN-2965 > URL: https://issues.jboss.org/browse/ISPN-2965 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Transactions > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Labels: 5.2.x > Fix For: 6.0.0.Alpha3 > > > In a distributed transactional cache with L1 enabled I can observe the following. > Prepare cache by adding an entry with Cache.put( k, v1 ). > 1. Node B starts with adding a changed value. Cache.put( k, v2 ) > 2. Node B TxDistributionInterceptor.visitPrepareCommand flushL1Caches sends invalidations. > 3. Node A calls Cache.get( k ) retrieves v1 and stores this value in L1. > 4. Node B proceeds with transaction. > The result is that Node A answers subsequent Cache.get(k) with v1 and Node B answers with v2. > It seems the invalidation is either send to early or must be synchronized in some way with the transaction. > Cache config: > <namedCache name="entity"> > <jmxStatistics enabled="true" /> > <clustering mode="dist"> > <stateTransfer fetchInMemoryState="false" timeout="20000" /> > <async /> > <l1 enabled="true" /> > <hash numOwners="1"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" > lockAcquisitionTimeout="15000" useLockStriping="false" /> > <eviction maxEntries="10000" strategy="LRU" /> > <expiration maxIdle="100000" wakeUpInterval="5000"/> > <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" /> > <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/> > </namedCache> -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3350) The server RHQ plugin should allow adding/removing caches, stores and endpoints

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3350?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3350: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/132 > The server RHQ plugin should allow adding/removing caches, stores and endpoints > ------------------------------------------------------------------------------- > > Key: ISPN-3350 > URL: https://issues.jboss.org/browse/ISPN-3350 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management, Server > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 6.0.0.Final > > > The Infinispan subsytem in the upstream as7 RHQ plugin allows adding caches from the RHQ console. We need to be able to do the same, and also add the same functionality to the endpoint subsystem. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3415) ISPN 5.1.6 download does not deliver org.infinispan.loaders.jdbc package

by Ben Cotton (JIRA)

[ https://issues.jboss.org/browse/ISPN-3415?page=com.atlassian.jira.plugin.... ] Ben Cotton commented on ISPN-3415: ---------------------------------- Hi Sanne. Thanks. I understand and agree that you guys should not be bogged down with carrying ancient 5.1.6 support requests. We have a terrifyingly slow process to officially move our builds to more compelling upgrades. As much as I want to, I can't upgrade to 5.3 at this time. :-( Feel no obligation to address this, but I'm gonna go for broke here (I feel like a stuck in the gutter 5.1.6 bumb with his cup held out looking for ISPN charity, but here goes): Do you have any recommendation for how I can get any help with https://community.jboss.org/thread/231588?tstart=0 ? Thanks for any consideration to respond. > ISPN 5.1.6 download does not deliver org.infinispan.loaders.jdbc package > ------------------------------------------------------------------------ > > Key: ISPN-3415 > URL: https://issues.jboss.org/browse/ISPN-3415 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.6.FINAL > Reporter: Ben Cotton > Assignee: Mircea Markus > Fix For: 5.1.x > > > The Infinispan 5.1.6 API (see http://docs.jboss.org/infinispan/5.1/apidocs/) documents the org.infinispan.loaders.jdbc package. However the Infinispan 5.1.6 distribution (http://jboss.org/infinispan/downloads/confirmation.html?downloadURL=http%... ) does not include the package within infinispan-core.jar -- 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, 8 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 August 2013