November 2012 - infinispan-issues

[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1855: ---------------------------------- Summary: Accessing a non-distributed cache from a RemoteCacheManager can break topology updates Key: ISPN-1855 URL: https://issues.jboss.org/browse/ISPN-1855 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.1.FINAL Reporter: Dan Berindei Assignee: Manik Surtani Fix For: 5.2.0.FINAL RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode). If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches. Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

3
4
0 / 0

[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken

by Paul Ferraro (Created) (JIRA)

AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken ------------------------------------------------------------------------------------- Key: ISPN-1583 URL: https://issues.jboss.org/browse/ISPN-1583 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.BETA5 Reporter: Paul Ferraro Assignee: Manik Surtani Priority: Critical When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke. Take the following code: AdvancedCache<K, V> baseCache; AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) { public void clear() { // custom clear logic } }; customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear(); In the above statement, the flag is not applied. The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection. In the case of with(ClassLoader) we have the opposite problem. customCache.with(customClassLoader).clear(); In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of decoratedCache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

7
10
0 / 0

[JBoss JIRA] (ISPN-2559) Util.loadClass() swallows certain types of exceptions

by Manik Surtani (JIRA)

Manik Surtani created ISPN-2559: ----------------------------------- Summary: Util.loadClass() swallows certain types of exceptions Key: ISPN-2559 URL: https://issues.jboss.org/browse/ISPN-2559 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.8.Final, 5.2.0.Beta4 Reporter: Manik Surtani Assignee: Manik Surtani Priority: Minor Fix For: 5.2.0.CR1, 5.2.0.Final, 5.1.9.Final Util.loadClassStrict re-wraps NoClassDefFoundErrors as ClassNotFoundExceptions. This is fine, since it is a fatal exception anyway, but it should at least log details out to enable debugging. -- 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

11 years, 4 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2562) TopologyAwareConsistent hash not working as designed

by Erik Salter (JIRA)

Erik Salter created ISPN-2562: --------------------------------- Summary: TopologyAwareConsistent hash not working as designed Key: ISPN-2562 URL: https://issues.jboss.org/browse/ISPN-2562 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.2.0.Beta4 Reporter: Erik Salter Assignee: Mircea Markus The TACH does not appear to be functioning as designed. I specify two separate machines (3 nodes each), but the backups are not distributed on the machines. Here are TRACE logs (not of this system, unfortunately), but with the toString() of the CHF used. Here are the specific implementations: session-cluster (session, accountToSessionId, clientToSessionId): TACHF erm-cluster (serviceGroup, qamAllocation, eigAllocation): SyncTACHF https://dl.dropbox.com/u/50401510/10.30.12.159/server.log.gz https://dl.dropbox.com/u/50401510/10.30.12.160/server.log.gz https://dl.dropbox.com/u/50401510/10.30.12.163/server.log.gz -- 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

11 years, 4 months

3
6
0 / 0

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

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-2575: ----------------------------------- Summary: 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: Feature Request Components: Querying Reporter: Anna Manukyan Assignee: Sanne Grinovero 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. You can find the test reproducing the issue here: https://github.com/andyuk1986/infinispan/blob/QUERY/query/src/test/java/o... -- 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

11 years, 4 months

2
3
0 / 0

[JBoss JIRA] (ISPN-2410) A PrepareCommand forwarded back to the originator can time out waiting on a key already locked by itself

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2410: ---------------------------------- Summary: A PrepareCommand forwarded back to the originator can time out waiting on a key already locked by itself Key: ISPN-2410 URL: https://issues.jboss.org/browse/ISPN-2410 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 If a rebalance happens while a prepare command is executing on a remote node, and the originator has become an owner, it makes sense to forward the command back to the originator to lock the keys (or just add them to the backup locks list). However, we don't keep the old consistent hashes around, so we don't know if the originator became an owner after invoking the remote command or was already an owner. So if the topology changed, we always forward the prepare back to the owner. Back on the originator, minTxTopologyId < currentTopologyId, so the prepare command has to wait for all the backup locks from pending transactions to be released. The problem is that we wait for the current transaction as well, causing a deadlock. Seen in OnePhaseXATest: {noformat} 18:07:46,873 TRACE (testng-OnePhaseXATest:TestCache) [RpcManagerImpl] NodeA-46125 broadcasting call PrepareCommand {modifications=[PutKeyValueCommand{key=key0, value=value, flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<NodeA-46125>:4353:local, cacheName='TestCache', topologyId=-1} to recipient list null 18:07:46,873 DEBUG (transport-thread-2,NodeA:TestCache) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache TestCache: new topology = CacheTopology{id=2, currentCH=ReplicatedConsistentHash{members=[NodeA-46125, NodeB-49450]}, pendingCH=null} 18:07:46,894 TRACE (OOB-1,ISPN,NodeB-49450:TestCache) [StateTransferManagerImpl] Forwarding command PrepareCommand {modifications=[PutKeyValueCommand{key=key0, value=value, flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<NodeA-46125>:4353:remote, cacheName='TestCache', topologyId=2} to new targets [NodeA-46125] 18:07:46,935 TRACE (OOB-3,ISPN,NodeA-46125:TestCache) [StateTransferInterceptor] handleTopologyAffectedCommand for command PrepareCommand {modifications=[PutKeyValueCommand{key=key0, value=value, flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<NodeA-46125>:4353:remote, cacheName='TestCache', topologyId=2}, originLocal=false 18:07:46,935 TRACE (OOB-3,ISPN,NodeA-46125:TestCache) [AbstractCacheTransaction] Transaction gtx=GlobalTransaction:<NodeA-46125>:4353:local potentially locks key key0? true 18:08:16,874 TRACE (testng-OnePhaseXATest:TestCache) [RpcManagerImpl] replication exception: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to NodeB-49450 {noformat} -- 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

11 years, 4 months

2
17
0 / 0

[JBoss JIRA] (ISPN-2473) Forwarding for non-transactional write commands should be asynchronous

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2473: ---------------------------------- Summary: Forwarding for non-transactional write commands should be asynchronous Key: ISPN-2473 URL: https://issues.jboss.org/browse/ISPN-2473 Project: Infinispan Issue Type: Sub-task Components: State transfer Affects Versions: 5.2.0.Beta3 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 A write command keeps a lock on the originator while doing the RPC on the actual owners, so forwarding the command back to the originator synchronously leads to a deadlock. Keeping track of the real originator for forwarded commands could allow us to avoid the deadlock, but it would be too complicated. OTOH, non-tx caches don't guarantee consistency, so we could just do the forwarding asynchronously. -- 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

11 years, 4 months

2
4
0 / 0

[JBoss JIRA] (ISPN-2552) Support concurrent updates for non-transactional caches

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2552: ----------------------------------- Summary: Support concurrent updates for non-transactional caches Key: ISPN-2552 URL: https://issues.jboss.org/browse/ISPN-2552 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.0.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.CR1 for non-transactional caches, when a key is updated, a local lock is acquired and also a lock on all the owning nodes as well. This is very inefficient for concurrent updates as it is very deadlock-prone. The following locking approach should solve this problem at the cost of an additional RPC: - 'k' is written on node A, owners(k)={B,C} - A forwards the given command to B - B acquires a lock on 'k' then it forwards it to the remaining owners: C - C applies the change and returns to B (no lock acquisition is needed) - B applies the result as well, releases the lock and returns the result of the operation to A. Note that even though this introduces an additional RPC (the forwarding), it behaves very well in conjunction with consistent-hash aware hotrod clients which connect directly to the lock owner. -- 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

11 years, 4 months

1
3
0 / 0

[JBoss JIRA] (ISPN-2209) HotRod client occasionally reports invalid magic number in elasticity tests

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2209: ------------------------------------- Summary: HotRod client occasionally reports invalid magic number in elasticity tests Key: ISPN-2209 URL: https://issues.jboss.org/browse/ISPN-2209 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.5.FINAL Environment: Hyperion w/32 nodes Reporter: Tristan Tarrant Assignee: Galder Zamarreño Fix For: 5.1.x, 5.2.0.FINAL During a 32-node elasticity tests, HotRod clients report "invalid magic number" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

3
10
0 / 0

[JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached

by Martin Gencur (JIRA)

Martin Gencur created ISPN-1822: ----------------------------------- Summary: Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached Key: ISPN-1822 URL: https://issues.jboss.org/browse/ISPN-1822 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.1.0.FINAL Environment: java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ; java version "1.7.0" Java(TM) SE Runtime Environment (build pxi3270-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled) Reporter: Martin Gencur Assignee: Manik Surtani This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot. Steps to reproduce the problem: 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory) 3) call cache.get("key1") 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter) I'll shortly issue a pull request with a test to ispn-core -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

6
30
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2012