April 2016 - 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

2
1
0 / 0

[JBoss JIRA] (ISPN-6235) ClusterTopologyManagerImpl join during cluster status recovery

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6235?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-6235. --------------------------------- > ClusterTopologyManagerImpl join during cluster status recovery > -------------------------------------------------------------- > > Key: ISPN-6235 > URL: https://issues.jboss.org/browse/ISPN-6235 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.3.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 8.2.0.CR1, 8.1.4.Final > > > If the joiner has the correct view id, but the current status is > RECOVERING_CLUSTER, we should wait for the cluster status recovery to > finish before adding the new member. > We are currently not doing that, so the new member could be erased by the status recovery process that's in progress. This can happen if the coordinator joiner already had been a member of the JGroups cluster for some time, and there's no view change when they actually start their caches (exactly the scenario in {{ConcurrentStartTest}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6233) JGroupsTransport shouldn't try to change the name of a connected channel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6233?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-6233. --------------------------------- Resolution: Done > JGroupsTransport shouldn't try to change the name of a connected channel > ------------------------------------------------------------------------ > > Key: ISPN-6233 > URL: https://issues.jboss.org/browse/ISPN-6233 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Beta2, 8.1.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.4.Final, 8.2.0.CR1 > > > If a {{ChannelLookup}} implementation returns an already-connected channel (i.e. {{channelLookup.shouldConnect() == false}}), {{channel.setName()}} will throw an exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5495) ConcurrentStartTest.testConcurrentStart random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5495?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reopened ISPN-5495: ----------------------------------- > ConcurrentStartTest.testConcurrentStart random failures > ------------------------------------------------------- > > Key: ISPN-5495 > URL: https://issues.jboss.org/browse/ISPN-5495 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > {noformat} > org.testng.internal.thread.ThreadTimeoutException: Method org.testng.internal.TestNGMethod.testConcurrentStart() didn't finish within the time-out 60000 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:253) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5495) ConcurrentStartTest.testConcurrentStart random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5495?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5495: ---------------------------------- Fix Version/s: 8.1.4.Final > ConcurrentStartTest.testConcurrentStart random failures > ------------------------------------------------------- > > Key: ISPN-5495 > URL: https://issues.jboss.org/browse/ISPN-5495 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 8.1.4.Final, 9.0.0.Final > > > {noformat} > org.testng.internal.thread.ThreadTimeoutException: Method org.testng.internal.TestNGMethod.testConcurrentStart() didn't finish within the time-out 60000 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:253) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5495) ConcurrentStartTest.testConcurrentStart random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5495?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-5495. --------------------------------- Resolution: Done > ConcurrentStartTest.testConcurrentStart random failures > ------------------------------------------------------- > > Key: ISPN-5495 > URL: https://issues.jboss.org/browse/ISPN-5495 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Final, 8.1.4.Final, 9.0.0.Alpha1, 8.2.1.Final > > > {noformat} > org.testng.internal.thread.ThreadTimeoutException: Method org.testng.internal.TestNGMethod.testConcurrentStart() didn't finish within the time-out 60000 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:253) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6233) JGroupsTransport shouldn't try to change the name of a connected channel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6233?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reopened ISPN-6233: ----------------------------------- > JGroupsTransport shouldn't try to change the name of a connected channel > ------------------------------------------------------------------------ > > Key: ISPN-6233 > URL: https://issues.jboss.org/browse/ISPN-6233 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Beta2, 8.1.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.CR1 > > > If a {{ChannelLookup}} implementation returns an already-connected channel (i.e. {{channelLookup.shouldConnect() == false}}), {{channel.setName()}} will throw an exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6233) JGroupsTransport shouldn't try to change the name of a connected channel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6233?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6233: ---------------------------------- Fix Version/s: 8.1.4.Final > JGroupsTransport shouldn't try to change the name of a connected channel > ------------------------------------------------------------------------ > > Key: ISPN-6233 > URL: https://issues.jboss.org/browse/ISPN-6233 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Beta2, 8.1.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.CR1, 8.1.4.Final > > > If a {{ChannelLookup}} implementation returns an already-connected channel (i.e. {{channelLookup.shouldConnect() == false}}), {{channel.setName()}} will throw an exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5883) Node can apply new topology after sending status response

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5883?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-5883. --------------------------------- Resolution: Done > Node can apply new topology after sending status response > --------------------------------------------------------- > > Key: ISPN-5883 > URL: https://issues.jboss.org/browse/ISPN-5883 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.0.1.Final, 7.2.5.Final, 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 8.1.4.Final, 8.2.0.Beta1 > > > {{LocalTopologyManagerImpl}} is responsible for sending the {{ClusterTopologyControlCommand(GET_STATUS)}} response, and when it sends the response it doesn't check the current view id against the new coordinator's view id. If the old coordinator already sent a topology update before the merge, that topology update might be processed after sending the status response. The new coordinator will send a topology update with a topology id of {{max(status response topology ids) + 1}}. The node will then process the topology update from the old coordinator, but it will ignore the topology update from the new coordinator with the same topology id. > This is extra common in the partition handling tests, e.g. {{BasePessimisticTxPartitionAndMergeTest}} subclasses, because the test "injects" the JGroups view on each node serially, and often the 4th node sends the status response before it gets the new view. > {noformat} > 22:16:37,776 DEBUG (remote-thread-NodeD-p26-t6:[]) [LocalTopologyManagerImpl] Sending cluster status response for view 10 > // Topology from NodeC > 22:16:37,778 DEBUG (transport-thread-NodeD-p28-t2:[]) [LocalTopologyManagerImpl] Updating local topology for cache pes-cache: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeC-46467, NodeD-30486]} > // Later, topology from NodeA > 22:16:37,827 DEBUG (transport-thread-NodeD-p28-t1:[]) [LocalTopologyManagerImpl] Ignoring late consistent hash update for cache pes-cache, current topology is 8: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeA-37631, NodeB-47846, NodeC-46467, NodeD-30486]} > {noformat} > As a solution, we can delay sending the status response until we have the same view as the coordinator (or a later one). We already check that the sender is the current coordinator before applying a topology update, so this will guarantee that the we don't apply other topology updates from the old coordinator. Since the status request is only sent after the new view was installed, this will not introduce any delays in the vast majority of cases. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4845) statetransfer.ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus fails randomly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4845?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reopened ISPN-4845: ----------------------------------- > statetransfer.ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus fails randomly > ------------------------------------------------------------------------------------- > > Key: ISPN-4845 > URL: https://issues.jboss.org/browse/ISPN-4845 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 5.2.10.Final > Reporter: Michal Vinkler > Assignee: Dan Berindei > Labels: 5.2.x > Fix For: 8.2.0.Beta1 > > > Seen with EAP 6.3.0.ER10, Infinispan 5.2.10 > Test org.infinispan.statetransfer.ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus randomly fails (seen on Solaris and HP-UX). > Might be the same as ISPN-4743. > Stacktraces: > HP-UX version > Error Message > {code} > Timed out waiting for rebalancing to complete on node ClusterTopologyManagerTest-NodeB-47391, expected member list is [ClusterTopologyManagerTest-NodeB-47391], current member list is [ClusterTopologyManagerTest-NodeB-47391, ClusterTopologyManagerTest-NodeC-55740]! > {code} > Stacktrace > {code} > java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node ClusterTopologyManagerTest-NodeB-47391, expected member list is [ClusterTopologyManagerTest-NodeB-47391], current member list is [ClusterTopologyManagerTest-NodeB-47391, ClusterTopologyManagerTest-NodeC-55740]! > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:203) > at org.infinispan.statetransfer.ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus(ClusterTopologyManagerTest.java:353) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > {code} > Also see standard output: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Infi... > Solaris version > Error Message > {code} > Thread already timed out waiting for event 3 left > {code} > Stacktrace > {code} > java.lang.IllegalStateException: Thread already timed out waiting for event 3 left > at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:150) > at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:135) > at org.infinispan.statetransfer.ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus(ClusterTopologyManagerTest.java:350) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > {code} > Also see standard output: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Infi... > Might be the same as ISPN-4743. > Downstream BZ was: https://bugzilla.redhat.com/show_bug.cgi?id=987461 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2016