November 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: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2103, https://github.com/infinispan/infinispan/pull/2005 (was: https://github.com/infinispan/infinispan/pull/2103) > 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.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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3678) In replicated mode writeSkew check is executed only on coordinator

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3678?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3678: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2191 > In replicated mode writeSkew check is executed only on coordinator > ------------------------------------------------------------------ > > Key: ISPN-3678 > URL: https://issues.jboss.org/browse/ISPN-3678 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > > Write skew check should be always performed on primary owner - however, in replicated and invalidation modes this is executed only on the coordinator (and primary owner). The bug is in ClusterDependentLogic.InvalidationLogic. > As a result, two conditional commands (e.g putIfAbsent) may both succeed to set the value. -- 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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3680: ------------------------------------- thanks for reporting this [~nfilotto], care to create a pull request for this? > Inconsistent way to use the column id in the JdbcBinaryCacheStore > ----------------------------------------------------------------- > > Key: ISPN-3680 > URL: https://issues.jboss.org/browse/ISPN-3680 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.CR1 > Reporter: Nicolas Filotto > Assignee: Mircea Markus > > I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id). -- 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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore

by Nicolas Filotto (JIRA)

[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ] Nicolas Filotto updated ISPN-3680: ---------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2190 > Inconsistent way to use the column id in the JdbcBinaryCacheStore > ----------------------------------------------------------------- > > Key: ISPN-3680 > URL: https://issues.jboss.org/browse/ISPN-3680 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.CR1 > Reporter: Nicolas Filotto > Assignee: Mircea Markus > > I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id). -- 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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore

by Nicolas Filotto (JIRA)

Nicolas Filotto created ISPN-3680: ------------------------------------- Summary: Inconsistent way to use the column id in the JdbcBinaryCacheStore Key: ISPN-3680 URL: https://issues.jboss.org/browse/ISPN-3680 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 6.0.0.CR1, 5.3.0.Final, 5.2.7.Final Reporter: Nicolas Filotto Assignee: Mircea Markus I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id). -- 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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3558: -------------------------------- Status: Open (was: Pull Request Sent) > PutForExternalRead won't work after a clear(), when both in same tx > ------------------------------------------------------------------- > > Key: ISPN-3558 > URL: https://issues.jboss.org/browse/ISPN-3558 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final, 6.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: William Burns > Priority: Blocker > Labels: dm > Fix For: 6.0.0.Final > > > {code} > public void testPutForExternalReadAfterClear() throws Exception { > cache.put(1, "v1"); > tm().begin(); > try { > cache.getAdvancedCache().clear(); > cache.putForExternalRead(1, "v1"); > assertEquals("v1", cache.get(1)); > } finally { > tm().commit(); > } > } > {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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3558: ---------------------------------------- [~sannegrinovero], as per our conversation last week, did you end up following up with [~mircea.markus] on using a flag to make the clear non-transactional (even if cache is transactional)? That would fix this issue. > PutForExternalRead won't work after a clear(), when both in same tx > ------------------------------------------------------------------- > > Key: ISPN-3558 > URL: https://issues.jboss.org/browse/ISPN-3558 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final, 6.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: William Burns > Priority: Blocker > Labels: dm > Fix For: 6.0.0.Final > > > {code} > public void testPutForExternalReadAfterClear() throws Exception { > cache.put(1, "v1"); > tm().begin(); > try { > cache.getAdvancedCache().clear(); > cache.putForExternalRead(1, "v1"); > assertEquals("v1", cache.get(1)); > } finally { > tm().commit(); > } > } > {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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3648: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.0.0.CR2 Resolution: Done > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2 > > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3396) Multiple classloader key store/lookup fails, even with storeAsBinary

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3396?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-3396. ------------------------------------ Fix Version/s: 6.0.0.Beta1 Resolution: Done > Multiple classloader key store/lookup fails, even with storeAsBinary > -------------------------------------------------------------------- > > Key: ISPN-3396 > URL: https://issues.jboss.org/browse/ISPN-3396 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: dm > Fix For: 6.0.0.Beta1 > > > Same key, multiple classloaders. Storing from one classloader cannot be found from the other, even when storeAsBinary is enabled (even with defensive=true). [IRC chat debugging issue|https://gist.github.com/galderz/63163644fee0c27d66c7]. -- 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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3396) Multiple classloader key store/lookup fails, even with storeAsBinary

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3396?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3396: ---------------------------------------- Fixed by ISPN-3477 > Multiple classloader key store/lookup fails, even with storeAsBinary > -------------------------------------------------------------------- > > Key: ISPN-3396 > URL: https://issues.jboss.org/browse/ISPN-3396 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: dm > > Same key, multiple classloaders. Storing from one classloader cannot be found from the other, even when storeAsBinary is enabled (even with defensive=true). [IRC chat debugging issue|https://gist.github.com/galderz/63163644fee0c27d66c7]. -- 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

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013