September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3464) Remove optional dependency in infinispan-query

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3464?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3464: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks! > Remove optional dependency in infinispan-query > ---------------------------------------------- > > Key: ISPN-3464 > URL: https://issues.jboss.org/browse/ISPN-3464 > Project: Infinispan > Issue Type: Task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > > http://ci.infinispan.org/viewLog.html?buildId=3019&tab=buildResultsDiv&bu... > making hibernate-search-analyzers and hibernate-search-infinispan dependency optional, makes the lucene integration test failing (IndexStoredIndexedCacheTest) with NoClassDefFoundError -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2956: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004193 > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > Labels: hotrod-java-client, remote-clients > Fix For: 6.1.0.Final > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2956: ----------------------------------------------- Takayoshi Kimura <tkimura(a)redhat.com> made a comment on [bug 1004193|https://bugzilla.redhat.com/show_bug.cgi?id=1004193] Product JIRA for ISPN-2956 > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > Labels: hotrod-java-client, remote-clients > Fix For: 6.1.0.Final > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3458) HotRod rolling upgrade target migrator should live in the Remote Store

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3458?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3458: ---------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/2042, https://github.com/infinispan/infinispan-server/pull/141 (was: https://github.com/infinispan/infinispan/pull/2042, https://github.com/infinispan/infinispan-server/pull/138) > HotRod rolling upgrade target migrator should live in the Remote Store > ---------------------------------------------------------------------- > > Key: ISPN-3458 > URL: https://issues.jboss.org/browse/ISPN-3458 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores, Migration tools, Remote protocols > Affects Versions: 6.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > Drop the upgrade-tools component and move the HotRod target migrator into the RemoteCacheStore -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3018) Implement a REST cache store which supports Rolling Upgrades

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3018?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3018: ---------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/2042, https://github.com/infinispan/infinispan-cachestore-rest/pull/2, https://github.com/infinispan/infinispan-server/pull/141 (was: https://github.com/infinispan/infinispan/pull/2042, https://github.com/infinispan/infinispan-cachestore-rest/pull/2) > Implement a REST cache store which supports Rolling Upgrades > ------------------------------------------------------------ > > Key: ISPN-3018 > URL: https://issues.jboss.org/browse/ISPN-3018 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 6.0.0.Final > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3466) LevelDB cachestore has uncompilable tests

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3466?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3466: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-cachestore-leveldb/pull/2 > LevelDB cachestore has uncompilable tests > ----------------------------------------- > > Key: ISPN-3466 > URL: https://issues.jboss.org/browse/ISPN-3466 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > Because of changes in the loader spi -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3466) LevelDB cachestore has uncompilable tests

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3466: ------------------------------------- Summary: LevelDB cachestore has uncompilable tests Key: ISPN-3466 URL: https://issues.jboss.org/browse/ISPN-3466 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 6.0.0.Beta1, 6.0.0.Final Because of changes in the loader spi -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3444) Server support for LevelDB cache store

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3444?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3444: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Server support for LevelDB cache store > -------------------------------------- > > Key: ISPN-3444 > URL: https://issues.jboss.org/browse/ISPN-3444 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 6.0.0.Beta1, 6.0.0.Final > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3465) Implement Redis based cachestore

by Guillaume Scheibel (JIRA)

Guillaume Scheibel created ISPN-3465: ---------------------------------------- Summary: Implement Redis based cachestore Key: ISPN-3465 URL: https://issues.jboss.org/browse/ISPN-3465 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 6.0.0.Alpha3 Reporter: Guillaume Scheibel Assignee: Guillaume Scheibel Priority: Minor -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3464) Remove optional dependency in infinispan-query

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3464?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3464: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2046 > Remove optional dependency in infinispan-query > ---------------------------------------------- > > Key: ISPN-3464 > URL: https://issues.jboss.org/browse/ISPN-3464 > Project: Infinispan > Issue Type: Task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > > http://ci.infinispan.org/viewLog.html?buildId=3019&tab=buildResultsDiv&bu... > making hibernate-search-analyzers and hibernate-search-infinispan dependency optional, makes the lucene integration test failing (IndexStoredIndexedCacheTest) with NoClassDefFoundError -- 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013