June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3231) Skip TransactionCompletionNotification for autoCommit transactions with 1PC commit

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3231?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3231: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Skip TransactionCompletionNotification for autoCommit transactions with 1PC commit > ---------------------------------------------------------------------------------- > > Key: ISPN-3231 > URL: https://issues.jboss.org/browse/ISPN-3231 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 5.2.6.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Alpha1 > > > autoCommit transactions with 1PC commit is unreliable for concurrent access, so locking + tx completion notification can be skipped. -- 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-3220) Integration tests rely on a nonexistent artifact

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3220?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3220: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Integration tests rely on a nonexistent artifact > ------------------------------------------------ > > Key: ISPN-3220 > URL: https://issues.jboss.org/browse/ISPN-3220 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.CR1 > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 6.0.0.Alpha1 > > > When running in a clean environment (no cached .m2 repo), {{AS Module Integration Tests}} fails with a broken dependency on {{org.jboss.as:jboss-as-dist:zip:7.2.0.Alpha1-redhat-4}}. > The following repos are queried: > {code} > [ERROR] jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/, releases=true, snapshots=true), > [ERROR] jboss-public-repository (https://repository.jboss.org/nexus/content/groups/public, releases=true, snapshots=true), > [ERROR] central (http://repo1.maven.org/maven2, releases=true, snapshots=false) > {code} > If this integration test relies on specific installs of JBoss AS/EAP/WildFly then they should be made optional, and *not* enabled by default as it breaks community builds/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-3209) Server operation to suppress state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3209?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3209: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Server operation to suppress state transfer > ------------------------------------------- > > Key: ISPN-3209 > URL: https://issues.jboss.org/browse/ISPN-3209 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1 > > > This issue is to provide a Server operation for the functionality implemented in ISPN-3140 -- 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-3208) Remove Solder dependency from Infinispan CDI

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3208?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3208: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Remove Solder dependency from Infinispan CDI > -------------------------------------------- > > Key: ISPN-3208 > URL: https://issues.jboss.org/browse/ISPN-3208 > Project: Infinispan > Issue Type: Feature Request > Components: CDI integration > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 5.2.7.Final, 6.0.0.Alpha1 > > > Solder was EOLd about 18 months ago. I would suggest updating to use DeltaSpike as that is a supported offering from Red Hat. -- 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-3176) Add tests for compatibility mode to server

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3176?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3176: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Add tests for compatibility mode to server > ------------------------------------------ > > Key: ISPN-3176 > URL: https://issues.jboss.org/browse/ISPN-3176 > Project: Infinispan > Issue Type: Task > Components: Server, Test Suite > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 6.0.0.Alpha1 > > -- 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-3151) Disable transaction table completed transactions cleanup service when total order is used

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3151?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3151: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Disable transaction table completed transactions cleanup service when total order is used > ----------------------------------------------------------------------------------------- > > Key: ISPN-3151 > URL: https://issues.jboss.org/browse/ISPN-3151 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.3.0.Beta2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 6.0.0.Alpha1 > > > the total order has it own mechanism to deal with out of order commit/rollback commands. The completed transactions map is not used, so we can disable the cleanup service and the avoid accessing the map. -- 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-3244) TopologyAwareSyncConsistentHashFactory should limit the number of segments per node

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3244?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3244: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > TopologyAwareSyncConsistentHashFactory should limit the number of segments per node > ----------------------------------------------------------------------------------- > > Key: ISPN-3244 > URL: https://issues.jboss.org/browse/ISPN-3244 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Alpha1 > > > Let's say we have a cluster with 5 nodes: A(r1), B(r2), C(r2), D(r3), E(r3) > TopologyAwareConsistentSyncHashFactory will spread the segments equally on each rack, meaning A will own 2x segments compared to the other nodes. > TopologyAwareConsistentHashFactory limits the maximum number per node, so that A owns just as many segments as the other nodes. With a slight limitation: the number of racks must be greater than numOwners, otherwise each rack must hold (at least) one copy of all the data. > TopologyAwareConsistentSyncHashFactory is a little random, so we can't distribute the data perfectly, but we can limit the number of segments on each node to something like 1.5x the average number of segments. -- 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-3263) LevelDB cachestore doesn't have a 5.3 parser + XSD

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3263?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3263: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > LevelDB cachestore doesn't have a 5.3 parser + XSD > -------------------------------------------------- > > Key: ISPN-3263 > URL: https://issues.jboss.org/browse/ISPN-3263 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1 > > -- 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-3237) Check if the lock acquisition can be removed for remote fetch entries in optimistic caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3237?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3237: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Check if the lock acquisition can be removed for remote fetch entries in optimistic caches > ------------------------------------------------------------------------------------------ > > Key: ISPN-3237 > URL: https://issues.jboss.org/browse/ISPN-3237 > Project: Infinispan > Issue Type: Enhancement > Components: Locking and Concurrency, Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: locking > Fix For: 6.0.0.Alpha1 > > > When a remote get is performed, it tries to lock the key in the originator. However: > * the originator is not an owner, so nothing will be locked > * in optimistic caches, the lock should be only acquired in the prepare phase -- 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-3236) Repeatable Read: Transactions are not isolated when read non-existing keys

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3236?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3236: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Repeatable Read: Transactions are not isolated when read non-existing keys > -------------------------------------------------------------------------- > > Key: ISPN-3236 > URL: https://issues.jboss.org/browse/ISPN-3236 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: isolation > Fix For: 6.0.0.Alpha1 > > > Repeatable read transaction is not isolated when they read a non-existing key. > tm.begin() > cache.get(k) //returns null > //in the meanwhile a transaction writes on k and commits > cache.get(k) //return the new value. IMO, this is not valid for > REPEATABLE_READ isolation level! > //TODO add a test case for all the write operations (except put map because it does not read the old value) > tm.begin() > cache.get(k) //returns null (op#1) > //in the meanwhile a transaction writes on k and commits > write operation performed: > * put: must return the same value as op#1 > * conditional put //if op#1 returns null the operation should be always successful (i.e. the key is updated, return true). Otherwise, the key remains unchanged (return false) > * replace: must return the same value as op#1 > * conditional replace: replace should be successful if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false). > * remote: must return the same value as op#1 > * conditional remove: the key should be removed if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false) > //TODO2: check if after a remove, the following get return null and the description above is still valid. -- 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 June 2013