December 2012 - infinispan-issues

[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

12 years

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

12 years

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

12 years

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

12 years

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

12 years

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

12 years

6
30
0 / 0

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2574: --------------------------------- Summary: Segment transfer not restarted if the owner fails Key: ISPN-2574 URL: https://issues.jboss.org/browse/ISPN-2574 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta4 Reporter: Radim Vansa Assignee: Adrian Nistor Priority: Critical Imagine this situation in distributed cache with 3 owners: 1) The segment X is owned by nodes A, B, C 2) Node B fails -> CH_UPDATE and then REBALANCE_START are transfered 3) Node D starts transfer of segment X from C 4) Node C fails -> another CH update is transfered 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- 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

12 years

6
11
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by Michal Linhard (JIRA)

Michal Linhard created ISPN-2577: ------------------------------------ Summary: Silence SuspectExceptions Key: ISPN-2577 URL: https://issues.jboss.org/browse/ISPN-2577 Project: Infinispan Issue Type: Bug Affects Versions: 5.2.0.Beta4 Reporter: Michal Linhard Assignee: Mircea Markus There are lots of SuspectExceptions in resilience test run: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... We managed to keep these under cover for 5.1.x branch. This is of course a cosmetic problem, but it polutes the log with unnecessary ERRORs. Parsed logs here: http://www.qa.jboss.com/~mlinhard/test_results/run54-parsed/ -- 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

12 years

3
4
0 / 0

[JBoss JIRA] (ISPN-2580) Do not request segments from all nodes at once

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2580: --------------------------------- Summary: Do not request segments from all nodes at once Key: ISPN-2580 URL: https://issues.jboss.org/browse/ISPN-2580 Project: Infinispan Issue Type: Enhancement Components: State transfer Affects Versions: 5.2.0.Beta5 Reporter: Radim Vansa Assignee: Mircea Markus When a new node joins large cluster filled with data, it gets the new CH and REBALANCE_START command, and requests data from all nodes at once (or almost all with even distribution of segments). It may be not able to handle this amount of transfers in parallel even at the JGroups level - this results in data sent to the node and discarded at the receiver, sent again and again. The number of StateRequestCommands(START_STATE_TRANSFER) should be limited so that the node is not congested. -- 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

12 years

3
8
0 / 0

[JBoss JIRA] (ISPN-2578) Two PrepareCommands in parallel cause ConcurrentModificationException

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2578: --------------------------------- Summary: Two PrepareCommands in parallel cause ConcurrentModificationException Key: ISPN-2578 URL: https://issues.jboss.org/browse/ISPN-2578 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa Assignee: Mircea Markus Situation: 1) Node A broadcasts PrepareCommand to nodes B, C 2) Node A leaves cluster, causing new topology to be installed 3) The command arrives to B and C, with lower topology than the current one 4) Both B and C forward the command to node D 5) D executes the two commands in parallel and finds out that A has left, therefore executing RollbackCommand In {{AbstractTxLockingInterceptor.visitRollbackCommand}} we call {{LockManagerImpl.unlockAll}} which iterates over the keys and unlocks them. As these two prepares aren't synchronized over the {{lockedKeys}} set, one may unlock and remove these keys while the other is iterating through them, causing {{ConcurrentModificationException}}. -- 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

12 years

3
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2012