October 2012 - infinispan-issues - Jboss List Archives

[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, 5 months

7
10
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, 5 months

2
17
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, 5 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, 5 months

6
30
0 / 0

[JBoss JIRA] (ISPN-2257) SimpleCacheRecoveryAdminTest.testForceCommitOnOtherNode still randomly failing

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2257: -------------------------------------- Summary: SimpleCacheRecoveryAdminTest.testForceCommitOnOtherNode still randomly failing Key: ISPN-2257 URL: https://issues.jboss.org/browse/ISPN-2257 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.2.0.Alpha4 The issue is failing again in master: {code}Failed tests: testForceCommitOnOtherNode(org.infinispan.tx.recovery.admin.SimpleCacheRecoveryAdminTest): expected:<false> but was:<true>{code} Unfortunately I don't have any logs. No idea if this is related to NBST at all :( -- 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, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (ISPN-928) Interceptor that allows invocations only when cluster is formed of N nodes

by Galder Zamarreño (JIRA)

Interceptor that allows invocations only when cluster is formed of N nodes -------------------------------------------------------------------------- Key: ISPN-928 URL: https://issues.jboss.org/browse/ISPN-928 Project: Infinispan Issue Type: Feature Request Components: Configuration, RPC Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final Following from https://github.com/pmuir/infinispan-examples/commit/f5d090092fa7b3660025b... It'd be great to have an configurable StrictCluster interceptor in Infinispan which would basically make all invocations wait until the cluster of N nodes has been formed. I think it'd be a great addition and would allow clients to verify whether the cluster actually forms without the need to verify whether data replicates...etc. In principle, the configuration would be at the CacheManager, i.e.: <transport strictNumMembers="4"... /> However, it could also be useful to configure it at the cache level. So, could maybe want to do this: I want cache X to allow invocations the moment I have 2 nodes (in spite of the cluster being formed of 4 noes), whereas I want cache Y to allow invocations once I have 3 nodes. Apart from an strict number of nodes, you could have a minimum number of nodes: allow invocations once I have 4 or more nodes. The strict value could still be useful to make sure intrusive machines don't get into the cluster, i.e. I expect 4 nodes in the cluster and if I have 5, something is wrong. I think it's an interesting concept that would get rid of cluster validation code in examples and RadarGun. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
4
0 / 0

[JBoss JIRA] (ISPN-2453) Locks not cleaned up - timeouts on write operations after contention is over

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2453: ------------------------------------- Summary: Locks not cleaned up - timeouts on write operations after contention is over Key: ISPN-2453 URL: https://issues.jboss.org/browse/ISPN-2453 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Blocker Fix For: 5.2.0.Beta3 By artificially creating contention on a write operation which needs to be serialized among different threads, we get timeout exceptions of "could not acquire lock after 10 seconds" even if the contention happens very briefly and then the pending writer is given all the time without other threads disturbing it. Created a stresstest to show it: ReplaceOperationStressTest -- 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, 5 months

2
5
0 / 0

[JBoss JIRA] (ISPN-2255) FineGrainedAtomicMap missing key, value pairs in some cluster nodes in distributed mode, embedded infinispan cache

by Zdenek Henek (JIRA)

Zdenek Henek created ISPN-2255: ---------------------------------- Summary: FineGrainedAtomicMap missing key,value pairs in some cluster nodes in distributed mode, embedded infinispan cache Key: ISPN-2255 URL: https://issues.jboss.org/browse/ISPN-2255 Project: Infinispan Issue Type: Feature Request Components: Fine-grained API Affects Versions: 5.1.5.FINAL Environment: Details about cluster: 1. Infinispan 5.1.5 2. java 7u5 64bit 3. linux 64bit (two nodes debian and one node ubuntu) 4. tomcat 7.0.28 5. jbossTM 4.16.0 JTA only Tomcat integration code is here: https://github.com/zvrablik/tomcatInfinispanSessionManager/tree/master/to... 6. all machines are on real hw ( no virtual machines), date and time is synchronized and shouldn't vary more than 1 second Reporter: Zdenek Henek Assignee: Mircea Markus I am using FineGrainedAtomicMap to store data into clustering distributed cache. When clustering set to replicated doesn't cause any issues or at least I haven't run into any. When I switch to distributed mode I don't see some key,value pairs in some nodes. This happens randomly. The numOwners is set to two and I have cluster of three nodes. more details: https://community.jboss.org/thread/203420?tstart=60 -- 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, 5 months

5
6
0 / 0

[JBoss JIRA] (ISPN-2250) Handle all the remaining comments for the NBST pull reques

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2250: ----------------------------------- Summary: Handle all the remaining comments for the NBST pull reques Key: ISPN-2250 URL: https://issues.jboss.org/browse/ISPN-2250 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Adrian Nistor Priority: Critical Fix For: 5.2.0.Alpha4 These are still visible even after the pull request is closed. Dan, please don't delete the t_nbst branch before handling these as we might loose them. -- 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, 5 months

2
8
0 / 0

[JBoss JIRA] (ISPN-2405) Pessimistic transactions can leak locks when cluster topology chnages

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2405: ----------------------------------- Summary: Pessimistic transactions can leak locks when cluster topology chnages Key: ISPN-2405 URL: https://issues.jboss.org/browse/ISPN-2405 Project: Infinispan Issue Type: Bug Components: State transfer, Transactions Affects Versions: 5.2.0.ALPHA1 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 5.2.0.CR1 -- 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, 5 months

2
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012