[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
3 months, 2 weeks
[JBoss JIRA] (ISPN-9112) getCache() should not wait for the initial state transfer by default
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-9112?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-9112:
-------------------------------------
This has a high chance of breaking query and the infinispan index manager. Fingers crossed ! :)
> getCache() should not wait for the initial state transfer by default
> --------------------------------------------------------------------
>
> Key: ISPN-9112
> URL: https://issues.jboss.org/browse/ISPN-9112
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Beta1
>
>
> {{DefaultCacheManager.getCache(name)}} normally blocks until the local node becomes a full member of the consistent hash and the rebalance has finished. This can cause problems when rebalancing is disabled, either explicitly by the administrator, or implicitly because the cache is in degraded mode.
> Blocking can be disabled with {{builder.clustering().stateTransfer().awaitInitialTransfer(false)}} ({{await-initial-transfer="false"}} in XML}}, but we should make the non-blocking behaviour the default. We should also deprecate the method and attribute to enable the blocking behaviour, and instead add a method to {{AdvancedCache}} to wait for the initial state transfer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-7800) Cluster always in Degraded Mode
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7800?page=com.atlassian.jira.plugin.... ]
Dan Berindei closed ISPN-7800.
------------------------------
Resolution: Duplicate Issue
Duplicate of ISPN-5290.
I also created ISPN-9112 to not wait for the initial transfer by default, so the servers can restart without the timeout error.
> Cluster always in Degraded Mode
> -------------------------------
>
> Key: ISPN-7800
> URL: https://issues.jboss.org/browse/ISPN-7800
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.6.Final, 9.0.0.Final
> Reporter: Pedro Ruivo
>
> Scenario:
> * 3 nodes, server mode with Partition handling enabled
> * 2 nodes are killed and bring back online
> * the nodes are unable to merge and the cluster remains in degraded mode.
> I suspect that the FORK channel/protocol is the culprit since the heartbeat command is never handled in the joiner node, but the coordinator receives a {{CacheNotFoundResponse}} quickly (i.e. without timeout). The request is received and "delivered" but never reaches Infinispan.
> When starting node 1 (logs from coordinator):
> {code}
> Received new cluster view: 5, isCoordinator = true, old status = COORDINATOR
> Received new cluster view: 5, isCoordinator = true, old status = COORDINATOR
> //hearbeat sent, ClusterTopologyManagerImpl.confirmMembersAvailable();
> Responses: value=CacheNotFoundResponse, received=true, suspected=false
> Node node01-47572 left while updating cache members
> //the view is not handled
> {code}
> When I started node 2:
> {code}
> Received new cluster view: 6, isCoordinator = true, old status = COORDINATOR
> Updating cluster members for all the caches. New list is [node03-48579, node01-47572, node02-32959]
> //hearbeat sent, ClusterTopologyManagerImpl.confirmMembersAvailable();
> Responses: Responses{
> node01-47572: value=SuccessfulResponse{responseValue=true} , received=true, suspected=false
> node02-32959: value=CacheNotFoundResponse, received=true, suspected=false}
> Node node02-32959 left while updating cache members
> //the view is not handled
> {code}
> It is always reproducible. The configuration is
> {code:xml}
> <replicated-cache name="default" mode="SYNC" batching="true">
> <partition-handling enabled="true"/>
> <locking isolation="REPEATABLE_READ"/>
> <state-transfer enabled="false"/>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9112) getCache() should not wait for the initial state transfer by default
by Dan Berindei (JIRA)
Dan Berindei created ISPN-9112:
----------------------------------
Summary: getCache() should not wait for the initial state transfer by default
Key: ISPN-9112
URL: https://issues.jboss.org/browse/ISPN-9112
Project: Infinispan
Issue Type: Enhancement
Components: Configuration, Core
Affects Versions: 9.2.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.3.0.Beta1
{{DefaultCacheManager.getCache(name)}} normally blocks until the local node becomes a full member of the consistent hash and the rebalance has finished. This can cause problems when rebalancing is disabled, either explicitly by the administrator, or implicitly because the cache is in degraded mode.
Blocking can be disabled with {{builder.clustering().stateTransfer().awaitInitialTransfer(false)}} ({{await-initial-transfer="false"}} in XML}}, but we should make the non-blocking behaviour the default. We should also deprecate the method and attribute to enable the blocking behaviour, and instead add a method to {{AdvancedCache}} to wait for the initial state transfer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9112) getCache() should not wait for the initial state transfer by default
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9112?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9112:
-------------------------------
Status: Open (was: New)
> getCache() should not wait for the initial state transfer by default
> --------------------------------------------------------------------
>
> Key: ISPN-9112
> URL: https://issues.jboss.org/browse/ISPN-9112
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Beta1
>
>
> {{DefaultCacheManager.getCache(name)}} normally blocks until the local node becomes a full member of the consistent hash and the rebalance has finished. This can cause problems when rebalancing is disabled, either explicitly by the administrator, or implicitly because the cache is in degraded mode.
> Blocking can be disabled with {{builder.clustering().stateTransfer().awaitInitialTransfer(false)}} ({{await-initial-transfer="false"}} in XML}}, but we should make the non-blocking behaviour the default. We should also deprecate the method and attribute to enable the blocking behaviour, and instead add a method to {{AdvancedCache}} to wait for the initial state transfer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-7439) InitialClusterSizeTest can hang during teardown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-7439?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-7439:
--------------------------------
Can you retest with https://issues.jboss.org/browse/JGRP-2262 (snapshot of JGroups) fixed? I suggest a smallish {{max_join_attempts}} attribute in GMS.
> InitialClusterSizeTest can hang during teardown
> -----------------------------------------------
>
> Key: ISPN-7439
> URL: https://issues.jboss.org/browse/ISPN-7439
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
>
> Test {{testInitialClusterSizeFail}} expects the nodes to time out in {{JGroupsTransport.waitForInitialNodes()}}, but in at least one case the timeout didn't happen. The test then tried to shut down the cache managers, but it hanged because another thread was holding the {{GlobalComponentRegistry}} lock:
> {noformat}
> "testng-InitialClusterSizeTest" #13 prio=5 os_prio=0 tid=0x00007f1874d1f000 nid=0x1778 waiting for monitor entry [0x00007f181bafc000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:280)
> - waiting to lock <0x0000000093c7afe0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:701)
> - locked <0x000000008a005b80> (a org.infinispan.manager.DefaultCacheManager)
> at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:656)
> at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:138)
> at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:786)
> 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:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "ForkThread-4,InitialClusterSizeTest" #167842 prio=5 os_prio=0 tid=0x00007f1824163800 nid=0x3316 waiting on condition [0x00007f17e62b9000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.jgroups.util.Util.sleep(Util.java:1818)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.firstOfAllClients(ClientGmsImpl.java:181)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:97)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1066)
> at org.jgroups.protocols.tom.TOA.down(TOA.java:73)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:302)
> at org.jgroups.protocols.RSVP.down(RSVP.java:102)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:900)
> at org.jgroups.JChannel.down(JChannel.java:644)
> at org.jgroups.JChannel._connect(JChannel.java:873)
> at org.jgroups.JChannel.connect(JChannel.java:369)
> - locked <0x0000000093c7aea0> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.connect(JChannel.java:360)
> - locked <0x0000000093c7aea0> (a org.jgroups.JChannel)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:221)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:211)
> at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
> - locked <0x0000000093c7afe0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:244)
> - locked <0x0000000093c7afe0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:666)
> at org.infinispan.remoting.transport.InitialClusterSizeTest.lambda$testInitialClusterSize$799(InitialClusterSizeTest.java:47)
> at org.infinispan.remoting.transport.InitialClusterSizeTest$$Lambda$2092/593962598.run(Unknown Source)
> at org.infinispan.test.AbstractInfinispanTest$RunnableWrapper.run(AbstractInfinispanTest.java:510)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "ForkThread-2,InitialClusterSizeTest" #167840 prio=5 os_prio=0 tid=0x00007f1824164800 nid=0x3314 waiting on condition [0x00007f17eec40000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.jgroups.util.Util.sleep(Util.java:1818)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.firstOfAllClients(ClientGmsImpl.java:181)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:97)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1066)
> at org.jgroups.protocols.tom.TOA.down(TOA.java:73)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:302)
> at org.jgroups.protocols.RSVP.down(RSVP.java:102)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:900)
> at org.jgroups.JChannel.down(JChannel.java:644)
> at org.jgroups.JChannel._connect(JChannel.java:873)
> at org.jgroups.JChannel.connect(JChannel.java:369)
> - locked <0x0000000093c7b7f0> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.connect(JChannel.java:360)
> - locked <0x0000000093c7b7f0> (a org.jgroups.JChannel)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:221)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:211)
> at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
> - locked <0x0000000093c7b930> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:244)
> - locked <0x0000000093c7b930> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:666)
> at org.infinispan.remoting.transport.InitialClusterSizeTest.lambda$testInitialClusterSize$799(InitialClusterSizeTest.java:47)
> at org.infinispan.remoting.transport.InitialClusterSizeTest$$Lambda$2092/593962598.run(Unknown Source)
> at org.infinispan.test.AbstractInfinispanTest$RunnableWrapper.run(AbstractInfinispanTest.java:510)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> See the full thread dump here: http://ci.infinispan.org/viewLog.html?buildId=49393&buildTypeId=bt9
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months