May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2575: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- 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

1 week, 1 day

2
1
0 / 0

[JBoss JIRA] (ISPN-5515) Preload only on the node that starts up the first

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5515?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5515: ------------------------------- Status: Open (was: New) > Preload only on the node that starts up the first > ------------------------------------------------- > > Key: ISPN-5515 > URL: https://issues.jboss.org/browse/ISPN-5515 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 7.2.2.Final, 8.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Alpha2 > > > Preloading happens before communicating with other nodes that might already have the cache running. When joining the existing members, the cache then waits to receive the first CH in which it is a member, and then deletes only the entries in the segments that it doesn't own in that CH. > The intention of this was to remove as little as possible from the existing data, e.g. if the first node to start up is not the one that was stopped last. But the preloaded entries are not replicated to the other nodes, so this can lead to inconsistencies. > It would be better to delay preloading until we know we are the first node to start up, but failing that we could clear the data container and the store before receiving the initial state. > Note that this will only allow preloading data from one node. Restoring data from more nodes is harder to do, and we will implement it as part of graceful restart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5517) JDBCBinaryStore size method should query count directly instead of iterating

by William Burns (JIRA)

William Burns created ISPN-5517: ----------------------------------- Summary: JDBCBinaryStore size method should query count directly instead of iterating Key: ISPN-5517 URL: https://issues.jboss.org/browse/ISPN-5517 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Reporter: William Burns Fix For: 8.0.0.Final JDBCBinaryStore size method iterates upon all of the rows in the database. We should instead use the getCountRowsSql from the table manipulation just like JDBCStringBasedStore. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5433) JSR-107 Support for standard annotations in client-server mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5433?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5433: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1218088|https://bugzilla.redhat.com/show_bug.cgi?id=1218088] from POST to MODIFIED > JSR-107 Support for standard annotations in client-server mode > -------------------------------------------------------------- > > Key: ISPN-5433 > URL: https://issues.jboss.org/browse/ISPN-5433 > Project: Infinispan > Issue Type: Feature Request > Components: JCache > Reporter: Matej Čimbora > Assignee: Tristan Tarrant > > Currently all the annotation-related logic resides in embedded module. Add support for HotRod implementation as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5516) SingleFileStore should skip loading from disk if value and metadata are not requested

by William Burns (JIRA)

William Burns created ISPN-5516: ----------------------------------- Summary: SingleFileStore should skip loading from disk if value and metadata are not requested Key: ISPN-5516 URL: https://issues.jboss.org/browse/ISPN-5516 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 8.0.0.Alpha1 Reporter: William Burns Fix For: 8.0.0.Final SingleFileStore internally stores all of the keys in memory. If the loader task doesn't require values or metadata there is no reason to go to disk as all of the information is already present in its key cache. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5033) Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5033?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5033: ---------------------------------- Fix Version/s: 8.0.0.Alpha2 8.0.0.Final > Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks > --------------------------------------------------------------------------------------------- > > Key: ISPN-5033 > URL: https://issues.jboss.org/browse/ISPN-5033 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.1.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 8.0.0.Alpha2, 8.0.0.Final > > > EmbeddedCacheManager has defineConfiguration(...) methods for defining a new cache configuration, but has no equivalent "undefine" method. Consequently, once defined, a cache manager will retains a reference to the cache configuration object for the lifetime of the cache manager. While this is normally not a big deal, the configuration objects generated by WildFly contain references to the classloaders of foreign modules. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5033) Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5033?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5033: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3516 > Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks > --------------------------------------------------------------------------------------------- > > Key: ISPN-5033 > URL: https://issues.jboss.org/browse/ISPN-5033 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.1.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Tristan Tarrant > Priority: Critical > > EmbeddedCacheManager has defineConfiguration(...) methods for defining a new cache configuration, but has no equivalent "undefine" method. Consequently, once defined, a cache manager will retains a reference to the cache configuration object for the lifetime of the cache manager. While this is normally not a big deal, the configuration objects generated by WildFly contain references to the classloaders of foreign modules. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4546: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1163727|https://bugzilla.redhat.com/show_bug.cgi?id=1163727] from ON_QA to VERIFIED > Possible stale lock when the primary owner leaves during rebalance > ------------------------------------------------------------------ > > Key: ISPN-4546 > URL: https://issues.jboss.org/browse/ISPN-4546 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha5, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Final > > > Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null > B sends prepareCommand(tx1, put(k, v)) to C, D > D adds backup locks and replies > C acquires lock, ready to send reply to B > A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E] > A, C and E install topology T+1, B and D do not > E requests and receives tx data from C, including tx1 > C leaves > B sees a SuspectException, sends rollbackCommand(tx1) to C, D > D removes tx1 > C has left, but is ignored > B reports to the user that the tx has been rolled back > B and D install topology T+1 (optional) > A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E] > A, B, D, E all install topology T+2 > E requests and receives state from D, but it does not remove tx1 > A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null > E now has a stale backup lock on k > It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E. > A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5515) Preload only on the node that starts up the first

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5515?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-5515: --------------------------------------- What guarantees do you have for this data to be valid? The definition of "first" seems rather subjective to me, and you have no idea how long ago that data was stored. Maybe this node has been down for the last month, while all other nodes worked and now this is being restarted. > Preload only on the node that starts up the first > ------------------------------------------------- > > Key: ISPN-5515 > URL: https://issues.jboss.org/browse/ISPN-5515 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 7.2.2.Final, 8.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Alpha2 > > > Preloading happens before communicating with other nodes that might already have the cache running. When joining the existing members, the cache then waits to receive the first CH in which it is a member, and then deletes only the entries in the segments that it doesn't own in that CH. > The intention of this was to remove as little as possible from the existing data, e.g. if the first node to start up is not the one that was stopped last. But the preloaded entries are not replicated to the other nodes, so this can lead to inconsistencies. > It would be better to delay preloading until we know we are the first node to start up, but failing that we could clear the data container and the store before receiving the initial state. > Note that this will only allow preloading data from one node. Restoring data from more nodes is harder to do, and we will implement it as part of graceful restart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5252) Override toString() of org.infinispan.registry.ScopedKey

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5252?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5252: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1203565|https://bugzilla.redhat.com/show_bug.cgi?id=1203565] from ON_QA to VERIFIED > Override toString() of org.infinispan.registry.ScopedKey > -------------------------------------------------------- > > Key: ISPN-5252 > URL: https://issues.jboss.org/browse/ISPN-5252 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.2.0.Alpha1, 7.1.1.Final > Reporter: Osamu Nagano > Assignee: Osamu Nagano > Fix For: 7.2.0.Beta2, 7.2.0.Final > > > A lock request timed out and the target key was dumped, but it was default {{toString()}} output of {{ScopedKey}}. This is unfriendly to developer. The wrapped original key should be dumped. > {noformat} > Caused by: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [org.infinispan.registry.ScopedKey@5b6f425] for requestor [GlobalTransaction:<AAA>:1568:remote]! Lock held by [GlobalTransaction:<BBB>:1271:local] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015