September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3318) Migrate data from one cache store to another

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3318?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3318: ----------------------------------- Fix Version/s: 6.0.0.Final > Migrate data from one cache store to another > -------------------------------------------- > > Key: ISPN-3318 > URL: https://issues.jboss.org/browse/ISPN-3318 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > Find a generic way to transfer data from one cache store to another, which could involve different Infinispan versions. This is handy to migrate file cache store based users to single file cache store (ISPN-2806). > Ideally, this should be added as a recipe for rolling upgrades. -- 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-3504) LevelDB Cache store in server doesn't keep data between restarts

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3504: ---------------------------------- Fix Version/s: 6.0.0.Beta1 (was: 6.0.0.CR1) > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta1 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- 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-3504) LevelDB Cache store in server doesn't keep data between restarts

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3504: ------------------------------------- Assignee: Tristan Tarrant (was: Mircea Markus) > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Fix For: 6.0.0.CR1 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- 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-3504) LevelDB Cache store in server doesn't keep data between restarts

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3504: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-cachestore-leveldb/pull/7 > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Fix For: 6.0.0.CR1 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- 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-3500) Conditional operation can generate inconsistencies in transactional mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3500?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3500: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Conditional operation can generate inconsistencies in transactional mode > ------------------------------------------------------------------------ > > Key: ISPN-3500 > URL: https://issues.jboss.org/browse/ISPN-3500 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > > conditional operation can be applied in the backup nodes. consider the following scenario: > {code} > k=v1 > tx1: write on key k value v2 > tx1: prepare and sends the commit... primary owner already applied v2 > tx2: [replace(k, v1, v3)] starts and reads from primary owner v2. ignoreReturnValue is false because the operation has failed to change k. > tx2: sends the prepare. in the backup owner, if perform oldValue.equals(value). however, the oldValue == v1 and value == v1. > {code} > the operation changed the key in the backup owner creating inconsistency. -- 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-3500) Conditional operation can generate inconsistencies in transactional mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3500?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3500: ----------------------------------- Fix Version/s: 6.0.0.Final Affects Version/s: 5.3.0.Final > Conditional operation can generate inconsistencies in transactional mode > ------------------------------------------------------------------------ > > Key: ISPN-3500 > URL: https://issues.jboss.org/browse/ISPN-3500 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final, 6.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > conditional operation can be applied in the backup nodes. consider the following scenario: > {code} > k=v1 > tx1: write on key k value v2 > tx1: prepare and sends the commit... primary owner already applied v2 > tx2: [replace(k, v1, v3)] starts and reads from primary owner v2. ignoreReturnValue is false because the operation has failed to change k. > tx2: sends the prepare. in the backup owner, if perform oldValue.equals(value). however, the oldValue == v1 and value == v1. > {code} > the operation changed the key in the backup owner creating inconsistency. -- 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-1540) Refactor distribution interceptor

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1540?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1540: -------------------------------- Fix Version/s: 6.0.0.Beta1 (was: 6.0.0.CR1) > Refactor distribution interceptor > --------------------------------- > > Key: ISPN-1540 > URL: https://issues.jboss.org/browse/ISPN-1540 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.1.0.BETA5 > Reporter: Mircea Markus > Assignee: William Burns > Fix For: 6.0.0.Beta1 > > > DistributionInterceptor, as it looks now is unnecessary complex. Before adding more functionality on top of it (i.e. ISPN-1539) it should be refactored: > - extract L1 logic into a different interceptor > - this would require moving the StateTransferLock logic into another interceptor as well > - now that we have separation between tx and non-tx caches, we can extract the remaining logic into TransactionalDistributionInterceptor and NonTransactional... -- 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-3518) 1PC can cause a window of inconsistency with L1 invalidation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3518?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3518: -------------------------------- Description: The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. Example: {quote} Node A owns k with value of v1 Node B has k in L1 with value of v1 tx1 started Node A put k -> v2 Node A sends invalidation Node A commits tx1 completed tx2 started Node B get k returns v1 from L1 tx2 completed Node B gets invalidation for k tx3 started Node B get k remotely retrieves v2 from Node A tx3 completed {quote} We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction. was: The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. Example: {quote} Node A owns k with value of v1 Node B has k in L1 with value of v1 tx1 started Node A put k -> v2 Node A sends invalidation Node A commits tx1 completed tx2 started Node B get k returns v1 from L1 tx2 completed Node B gets invalidation for k tx2 started Node B get k remotely retrieves v2 from Node A tx2 completed {quote} We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction. > 1PC can cause a window of inconsistency with L1 invalidation > ------------------------------------------------------------ > > Key: ISPN-3518 > URL: https://issues.jboss.org/browse/ISPN-3518 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Reporter: William Burns > Assignee: William Burns > > The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. > Example: > {quote} > Node A owns k with value of v1 > Node B has k in L1 with value of v1 > tx1 started > Node A put k -> v2 > Node A sends invalidation > Node A commits > tx1 completed > tx2 started > Node B get k returns v1 from L1 > tx2 completed > Node B gets invalidation for k > tx3 started > Node B get k remotely retrieves v2 from Node A > tx3 completed > {quote} > We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction. -- 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-2177) Refactor AbstractCacheTransaction

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2177?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2177: -------------------------------- Issue Type: Feature Request (was: Bug) > Refactor AbstractCacheTransaction > ----------------------------------- > > Key: ISPN-2177 > URL: https://issues.jboss.org/browse/ISPN-2177 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.1.2.FINAL > Reporter: Mircea Markus > Assignee: William Burns > Labels: refactoring, transaction > Fix For: 6.0.0.CR1 > > > There are several collections holding transaction related information in the AbstractCacheTransaction: > - lockedKeys: this holds all the keys that were actually locked on the local node > - affectedKeys: this holds all the keys that were acquired by the transaction allover the cluster > - backupKeyLocks: this holds all the locks for which the local node is a secondary data owner. > To do: > - affectedKeys belongs to LocalCacheTransaction(subclass) and no point in having it in the AbstractCacheTransaction > - a better name for affectedKeys might be "clusterLockedKey" and for lockedKeys --> localLokedKeys > - also add a Javadoc explaining the correlation between these key groups -- 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-3518) 1PC can cause a window of inconsistency with L1 invalidation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3518?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3518: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > 1PC can cause a window of inconsistency with L1 invalidation > ------------------------------------------------------------ > > Key: ISPN-3518 > URL: https://issues.jboss.org/browse/ISPN-3518 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Reporter: William Burns > Assignee: William Burns > > The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. > Example: > {quote} > Node A owns k with value of v1 > Node B has k in L1 with value of v1 > tx1 started > Node A put k -> v2 > Node A sends invalidation > Node A commits > tx1 completed > tx2 started > Node B get k returns v1 from L1 > tx2 completed > Node B gets invalidation for k > tx2 started > Node B get k remotely retrieves v2 from Node A > tx2 completed > {quote} > We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction. -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013