March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3976) Protobuf marshalling on Indexed server caches interferes with keySet and bulk marshalling

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3976?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3976: ------------------------------------- It seems you need a clustered (not fully replicated) cache to reproduce this. It does not happen in any other circumstances. Then you need to add some logging here and there in m/r code to highlight exceptions that otherwise get swallowed, and here is what you get: {code} Caused by: java.lang.ClassCastException: org.infinispan.query.remote.indexing.ProtobufValueWrapper cannot be cast to [B at org.infinispan.server.hotrod.util.BulkUtil$KeyMapper.map(BulkUtil.java:40) [infinispan.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceManagerImpl$2.apply(MapReduceManagerImpl.java:197) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceManagerImpl$2.apply(MapReduceManagerImpl.java:192) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.container.DefaultDataContainer$1.apply(DefaultDataContainer.java:381) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.container.DefaultDataContainer$1.apply(DefaultDataContainer.java:377) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.ConcurrentParallelHashMapV8$1.apply(ConcurrentParallelHashMapV8.java:48) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ForEachMappingTask.compute(EquivalentConcurrentHashMapV8.java:4891) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.CountedCompleter.exec(CountedCompleter.java:681) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinTask.doExec(ForkJoinTask.java:264) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinTask.doInvoke(ForkJoinTask.java:360) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinTask.invoke(ForkJoinTask.java:692) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.forEach(EquivalentConcurrentHashMapV8.java:3589) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.commons.util.concurrent.jdk8backported.ConcurrentParallelHashMapV8.forEach(ConcurrentParallelHashMapV8.java:44) [infinispan-commons.jar:7.0.0-SNAPSHOT] at org.infinispan.container.DefaultDataContainer.executeTask(DefaultDataContainer.java:377) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:192) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:91) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:1008) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:947) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:979) [infinispan-core.jar:7.0.0-SNAPSHOT] at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:975) [infinispan-core.jar:7.0.0-SNAPSHOT] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] at org.jboss.threads.JBossThread.run(JBossThread.java:122) {code} Finally. > Protobuf marshalling on Indexed server caches interferes with keySet and bulk marshalling > ----------------------------------------------------------------------------------------- > > Key: ISPN-3976 > URL: https://issues.jboss.org/browse/ISPN-3976 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4111) Fix dependency tree still leaking Netty 3 on Hot Rod classpath

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4111?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4111: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Fix dependency tree still leaking Netty 3 on Hot Rod classpath > -------------------------------------------------------------- > > Key: ISPN-4111 > URL: https://issues.jboss.org/browse/ISPN-4111 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Alpha2 > > > Netty 3 is still present in the project because of missed exclusions via Narayana JTA. It's also still being used. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-4035) SingleFileStore.FileEntry.compareTo is wrong

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4035?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4035: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1073334|https://bugzilla.redhat.com/show_bug.cgi?id=1073334] from ON_QA to VERIFIED > SingleFileStore.FileEntry.compareTo is wrong > -------------------------------------------- > > Key: ISPN-4035 > URL: https://issues.jboss.org/browse/ISPN-4035 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 630 > Fix For: 7.0.0.Alpha1 > > > Because {{FileEntry.compareTo(fe)}} never returns 0, allocated entries are not properly removed from the free list (at least on IBM JDK 6). -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3762) Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3762?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3762: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1034719|https://bugzilla.redhat.com/show_bug.cgi?id=1034719] from ON_QA to VERIFIED > Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-3762 > URL: https://issues.jboss.org/browse/ISPN-3762 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.0.Final > Reporter: Jiří Holuša > Assignee: Galder Zamarreño > Attachments: log.txt > > > The test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fails every time on all environments. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3845) CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3845?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3845: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1060311|https://bugzilla.redhat.com/show_bug.cgi?id=1060311] from ON_QA to VERIFIED > CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches > ------------------------------------------------------------------- > > Key: ISPN-3845 > URL: https://issues.jboss.org/browse/ISPN-3845 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 621, testsuite_stability > Fix For: 7.0.0.Alpha1 > > > the flag is not forcing the EntryWrappingInterceptor to wrap the entry. the result is the entry will not be stored in the cache. > It's causing the random failures in: > {noformat} > HotRodReplicationTest.testReplicatedPutWithTopologyChanges > HotRod11ReplicationTest.testReplicatedPutWithTopologyChanges > HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > {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

1
0
0 / 0

[JBoss JIRA] (ISPN-3868) Deadlock in RemoteCache getAsync

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3868?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3868: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1073331|https://bugzilla.redhat.com/show_bug.cgi?id=1073331] from ON_QA to VERIFIED > Deadlock in RemoteCache getAsync > -------------------------------- > > Key: ISPN-3868 > URL: https://issues.jboss.org/browse/ISPN-3868 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Environment: RemoteCahe component of 6.0.0.Final > Reporter: Alexander Furer > Assignee: Mircea Markus > Labels: 630, remote > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Here is the implementation of remoteCahe.getAsync() : > {code} > public NotifyingFuture<V> getAsync(final K key) { > assertRemoteCacheManagerIsStarted(); > final NotifyingFutureImpl<V> result = new NotifyingFutureImpl<V>(); > Future<V> future = executorService.submit(new Callable<V>() { > @Override > public V call() throws Exception { > V toReturn = get(key); > result.notifyFutureCompletion(); > return toReturn; > } > }); > result.setExecuting(future); > return result; > } > {code} > 2 problems here : > 1. Callable's call method might be called BEFORE calling client had a chance to add listener (i.e. getAsync is not returned yet), in this case its' listener futureDone method will never be called. > 2. Even case #1 has not happened and notifyFutureCompletion is called on listener, but the future is not resolved yet : "call" has not returned, that's why the future that is passed to listener is not resolved, and calling future.get from listener blocks forever. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3956: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1059814|https://bugzilla.redhat.com/show_bug.cgi?id=1059814] from ON_QA to VERIFIED > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3932) FineGrainedAtomicMap with REPEATABLE_READ sees modifications from other transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3932?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3932: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1047905|https://bugzilla.redhat.com/show_bug.cgi?id=1047905] from ON_QA to VERIFIED > FineGrainedAtomicMap with REPEATABLE_READ sees modifications from other transactions > ------------------------------------------------------------------------------------ > > Key: ISPN-3932 > URL: https://issues.jboss.org/browse/ISPN-3932 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final, 6.0.1.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Labels: 621 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > FineGrainedAtomicMap doesn't respect the REPEATABLE_READ isolation level: a transaction holding a FGAM reference will see subkeys added by another concurrent transaction. > A test with PESSIMISTIC locking is here: https://github.com/danberindei/infinispan/commit/526ae4c414009b2a95b39a65... > We need to test OPTIMISTIC locking and the coarse-grained AtomicMap as well. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-4066) org.infinispan.query.dsl.Query.getResultSize() gives wrong results when used in remote mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4066?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4066: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1073098|https://bugzilla.redhat.com/show_bug.cgi?id=1073098] from ON_QA to VERIFIED > org.infinispan.query.dsl.Query.getResultSize() gives wrong results when used in remote mode > ------------------------------------------------------------------------------------------- > > Key: ISPN-4066 > URL: https://issues.jboss.org/browse/ISPN-4066 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 6.3remotequeries, 621 > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > It works in embedded mode but not in remote mode. No test case yet for this issue, but it was reported by a user on #infinispan irc. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3803) Stale locks during state transfer in non-tx caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3803?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3803: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1073327|https://bugzilla.redhat.com/show_bug.cgi?id=1073327] from ON_QA to VERIFIED > Stale locks during state transfer in non-tx caches > -------------------------------------------------- > > Key: ISPN-3803 > URL: https://issues.jboss.org/browse/ISPN-3803 > Project: Infinispan > Issue Type: Bug > Components: State Transfer, Transactions > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 621, testsuite_stability > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The problem is that {{SingleKeyNonTxInvocationContext.addLockedKey()}} only sets a {{isLocked}} flag, the actual key is set when the entry is wrapped and inserted in the context. If the topology changes between the lock acquisition and the entry wrapping, {{SingleKeyNonTxInvocationContext.getLockedKeys()}} will return an empty set and the lock won't be released. > Future commands won't try to acquire a lock on this node, so the stale lock is harmless most of the time. But if there was already a command waiting for the lock, that command will time out (instead of retrying on the new primary owner). > This causes random failures in NonTxPutIfAbsentDuringJoinStressTest: > {noformat} > 12:34:50,960 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=key_52, value=value_52_2, flags=null, putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@478c9796] > 12:34:50,960 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [NonTransactionalLockingInterceptor] Are (NodeA-19338) we the lock owners for key 'key_52'? true > 12:34:50,960 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [LockManagerImpl] Attempting to lock key_52 with acquisition timeout of 10000 millis > 12:34:50,962 TRACE (remote-thread-1,NodeA:___defaultcache) [NonTransactionalLockingInterceptor] Are (NodeA-19338) we the lock owners for key 'key_52'? true > 12:34:50,962 TRACE (remote-thread-1,NodeA:___defaultcache) [LockManagerImpl] Attempting to lock key_52 with acquisition timeout of 10000 millis > 12:34:50,965 TRACE (asyncTransportThread-0,NodeA:___defaultcache) [StateConsumerImpl] Received new topology for cache ___defaultcache, isRebalance = false, isMember = true, topology = CacheTopology{id=4, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-19338, NodeB-49967, NodeC-56763]}, pendingCH=null} > 12:34:50,966 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [LockManagerImpl] Successfully acquired lock key_52! > *** 12:34:50,966 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [EntryWrappingInterceptor] Wrapping entry 'key_52'? false > 12:34:50,966 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [StateTransferInterceptor] Retrying command because of topology change: PutKeyValueCommand{key=key_52, value=value_52_2, flags=null, putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true} > 12:34:50,978 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [NonTransactionalLockingInterceptor] Are (NodeA-19338) we the lock owners for key 'key_52'? false > 12:34:50,978 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [EntryWrappingInterceptor] Wrapping entry 'key_52'? false > 12:34:50,978 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [BaseDistributionInterceptor] I'm not the primary owner, so sending the command to the primary owner(NodeC-56763) in order to be forwarded > 12:34:51,007 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [EntryWrappingInterceptor] The return value is value_52_0 > 12:35:00,963 TRACE (remote-thread-1,NodeA:___defaultcache) [ReentrantPerEntryLockContainer] Timed out attempting to acquire lock for key key_52 after 10 seconds > 12:35:00,963 DEBUG (remote-thread-1,NodeA:___defaultcache) [LockManagerImpl] Failed to acquire lock key_52, owner is Thread[ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest,5,] > 12:35:00,963 DEBUG (remote-thread-1,NodeA:___defaultcache) [LockManagerImpl] This transaction (Thread[remote-thread-1,NodeA,5,main]) already owned locks [] > 12:35:00,966 ERROR (testng-NonTxPutIfAbsentDuringJoinStressTest:) [UnitTestTestNGListener] Test testNodeJoiningDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringJoinStressTest) failed. > java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeA-19338, see cause for remote stack trace > Caused by: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [key_52] for requestor [Thread[remote-thread-1,NodeA,5,main]]! Lock held by [Thread[ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest,5,]]{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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014