[JBoss JIRA] (ISPN-8989) Administration console - Counters don't work in standalone mode
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-8989?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-8989:
--------------------------------------
Status: Open (was: New)
> Administration console - Counters don't work in standalone mode
> ---------------------------------------------------------------
>
> Key: ISPN-8989
> URL: https://issues.jboss.org/browse/ISPN-8989
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.2.0.Final
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
>
> start the server in standalone clustered mode:
> - bin/standalone.sh -c clustered.xml
> - click on cache container -> Counters tab -> Create new counter -> create counter e.g. (name: new, initial value 5)
> This results in error pop up:
> WFLYCTL0030: No resource definition is registered for address [ ("profile" => "standalone"), ("subsystem" => "datagrid-infinispan"), ("cache-container" => "clustered"), ("counters" => "COUNTERS") ]
> Please note that this works in domain mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8989) Administration console - Counters don't work in standalone mode
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-8989?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic reassigned ISPN-8989:
-----------------------------------------
Assignee: Vladimir Blagojevic
> Administration console - Counters don't work in standalone mode
> ---------------------------------------------------------------
>
> Key: ISPN-8989
> URL: https://issues.jboss.org/browse/ISPN-8989
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.2.0.Final
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
>
> start the server in standalone clustered mode:
> - bin/standalone.sh -c clustered.xml
> - click on cache container -> Counters tab -> Create new counter -> create counter e.g. (name: new, initial value 5)
> This results in error pop up:
> WFLYCTL0030: No resource definition is registered for address [ ("profile" => "standalone"), ("subsystem" => "datagrid-infinispan"), ("cache-container" => "clustered"), ("counters" => "COUNTERS") ]
> Please note that this works in domain mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8976) 2 subclusters failed to merge to 1 cluster - IllegalLifecycleStateException
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8976?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-8976:
------------------------------------
[~robertcernak] If you do not need Conflict Resolution on partition merge then I suggest that you configure your cache to use MergePolicy.NONE and the CR phase, which appears to be causing the problem, will be skipped.
My intention is to fix this issue, ideally in time for 9.3.0.Final but I cannot guarantee this due to other commitments etc.
> 2 subclusters failed to merge to 1 cluster - IllegalLifecycleStateException
> ---------------------------------------------------------------------------
>
> Key: ISPN-8976
> URL: https://issues.jboss.org/browse/ISPN-8976
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.1.4.Final
> Reporter: Robert Cernak
> Assignee: Ryan Emerson
> Attachments: logs.zip
>
>
> At the beginning I have main cluster consisted of 8 nodes.
> Then I disconnected main switch on which these nodes were connected.
> This leaded to separating main cluster to 2 subclusters - first with 2 nodes and second with 6 nodes. This was expected.
> After that I rebooted the nodes. After reboot, nodes again correctly formed 2 subclusters with 2 and 6 members.
> After a long time when all nodes were stable with low cpu load, I connected the main switch back which should lead to recreation of main cluster with 8 controllers.
> However main cluster did not recovered:
> subcluster2 did not change - still had 6 nodes connected - no new members
> subcluster1 - nodes did not connect with subcluster2 and after cca 30min they left the cluster.
> When I checked infinispan logs of node1 from 1st subcluster I had IllegalLifecycleStateException for every created cache (see included logs.zip):
> [transport-thread-744a974a-2811-4f79-ac63-f32daf005d7f-p4-t6] (ClusterCacheStatus.java:599) - ISPN000228: Failed to recover cache XXX state after the current node became the coordinator
> org.infinispan.IllegalLifecycleStateException: Cache container has been stopped and cannot be reused. Recreate the cache container.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-7439) InitialClusterSizeTest can hang during teardown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7439?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-7439:
------------------------------------
[~belaban] unfortunately I wasn't able to reproduce it again after I opened the issue, so I won't be able to confirm that the JGRP-2262 fix also fixes this. The fix looks good to me, but I'd also remove the {{Thread.sleep(500)}} from {{firstOfAllClients()}}: if the join algorithm needs a delay in this case, it should be explicit in {{joinInternal()}}.
> 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)
6 years
[JBoss JIRA] (ISPN-5783) Cache.put(null, null) leaks an implicit transaction
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5783?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5783:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.3.0.Beta1
(was: 8.1.0.Final)
(was: 8.1.0.Alpha1)
Resolution: Done
> Cache.put(null, null) leaks an implicit transaction
> ---------------------------------------------------
>
> Key: ISPN-5783
> URL: https://issues.jboss.org/browse/ISPN-5783
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Beta1
>
>
> {{null}} keys and values are not supported, and {{Cache.put(null, null)}} will throw a {{NullPointerException}}. But the null check happens after the implicit transaction was created, and it doesn't clean it up before throwing the exception.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9025) Transaction leak when API invoked with invalid arguments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9025?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9025:
-------------------------------
Affects Version/s: 9.2.2.Final
> Transaction leak when API invoked with invalid arguments
> --------------------------------------------------------
>
> Key: ISPN-9025
> URL: https://issues.jboss.org/browse/ISPN-9025
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.10.Final, 9.2.2.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Beta1
>
>
> {{APINonTxTest}} is leaking transactions in {{testReplaceNullKeyParameter()}} and related methods (for transaction configurations). The implicit transaction is created and then a {{NullPointerException}} is thrown because of invalid arguments. The transaction stays in {{TransactionTable}} forever making the {{TransactionTable.stop()}} slow.
> {{testStopClearsData()}} runs slow (30sec) because it waits for the leaking transactions to finish (in a total of 2 min since the test is executed 4 times for different tx configurations)
> IMO, the best solution would be a {{Supplier}} or {{IntFunction}} and only create the {{InvocationContext}} and implicit transaction in the last moment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9025) Transaction leak when API invoked with invalid arguments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9025?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9025:
-------------------------------
Component/s: Core
> Transaction leak when API invoked with invalid arguments
> --------------------------------------------------------
>
> Key: ISPN-9025
> URL: https://issues.jboss.org/browse/ISPN-9025
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.10.Final, 9.2.2.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Beta1
>
>
> {{APINonTxTest}} is leaking transactions in {{testReplaceNullKeyParameter()}} and related methods (for transaction configurations). The implicit transaction is created and then a {{NullPointerException}} is thrown because of invalid arguments. The transaction stays in {{TransactionTable}} forever making the {{TransactionTable.stop()}} slow.
> {{testStopClearsData()}} runs slow (30sec) because it waits for the leaking transactions to finish (in a total of 2 min since the test is executed 4 times for different tx configurations)
> IMO, the best solution would be a {{Supplier}} or {{IntFunction}} and only create the {{InvocationContext}} and implicit transaction in the last moment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9025) Transaction leak when API invoked with invalid arguments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9025?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9025:
-------------------------------
Affects Version/s: 8.2.10.Final
> Transaction leak when API invoked with invalid arguments
> --------------------------------------------------------
>
> Key: ISPN-9025
> URL: https://issues.jboss.org/browse/ISPN-9025
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.10.Final, 9.2.2.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Beta1
>
>
> {{APINonTxTest}} is leaking transactions in {{testReplaceNullKeyParameter()}} and related methods (for transaction configurations). The implicit transaction is created and then a {{NullPointerException}} is thrown because of invalid arguments. The transaction stays in {{TransactionTable}} forever making the {{TransactionTable.stop()}} slow.
> {{testStopClearsData()}} runs slow (30sec) because it waits for the leaking transactions to finish (in a total of 2 min since the test is executed 4 times for different tx configurations)
> IMO, the best solution would be a {{Supplier}} or {{IntFunction}} and only create the {{InvocationContext}} and implicit transaction in the last moment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9025) Transaction leak when API invoked with invalid arguments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9025?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9025:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.3.0.Beta1
Resolution: Done
> Transaction leak when API invoked with invalid arguments
> --------------------------------------------------------
>
> Key: ISPN-9025
> URL: https://issues.jboss.org/browse/ISPN-9025
> Project: Infinispan
> Issue Type: Bug
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Beta1
>
>
> {{APINonTxTest}} is leaking transactions in {{testReplaceNullKeyParameter()}} and related methods (for transaction configurations). The implicit transaction is created and then a {{NullPointerException}} is thrown because of invalid arguments. The transaction stays in {{TransactionTable}} forever making the {{TransactionTable.stop()}} slow.
> {{testStopClearsData()}} runs slow (30sec) because it waits for the leaking transactions to finish (in a total of 2 min since the test is executed 4 times for different tx configurations)
> IMO, the best solution would be a {{Supplier}} or {{IntFunction}} and only create the {{InvocationContext}} and implicit transaction in the last moment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years