[JBoss JIRA] (WFLY-10168) Unable to set global-client-thread-pool-max-size without setting global-client-scheduled-thread-pool-max-size and vice versa
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFLY-10168?page=com.atlassian.jira.plugin... ]
Martin Styk updated WFLY-10168:
-------------------------------
Description:
Logic in messaging integration doesn't allow configuring property {{global-client-thread-pool-max-size}} without setting {{global-client-scheduled-thread-pool-max-size}} and vice versa [1].
{code}
if (threadPoolMaxSize.isDefined()) {
threadPoolMaxSizeValue = GLOBAL_CLIENT_THREAD_POOL_MAX_SIZE.resolveModelAttribute(context, operation).asInt();
} else if (sysprops.containsKey(THREAD_POOL_MAX_SIZE_PROPERTY_KEY)) {
threadPoolMaxSizeValue = Integer.parseInt(sysprops.getProperty(THREAD_POOL_MAX_SIZE_PROPERTY_KEY));
} else {
// property is not configured using sysprop or explicit attribute
threadPoolMaxSizeValue = null;
}
if (scheduledThreadPoolMaxSize.isDefined()) {
scheduledThreadPoolMaxSizeValue = GLOBAL_CLIENT_SCHEDULED_THREAD_POOL_MAX_SIZE.resolveModelAttribute(context, operation).asInt();
} else if (sysprops.containsKey(SCHEDULED_THREAD_POOL_SIZE_PROPERTY_KEY)) {
scheduledThreadPoolMaxSizeValue = Integer.parseInt(sysprops.getProperty(SCHEDULED_THREAD_POOL_SIZE_PROPERTY_KEY));
} else {
// property is not configured using sysprop or explicit attribute
scheduledThreadPoolMaxSizeValue = null;
}
if (threadPoolMaxSizeValue != null && scheduledThreadPoolMaxSizeValue != null) {
MessagingLogger.ROOT_LOGGER.debugf("Setting global client thread pool size to: regular=%s, scheduled=%s", threadPoolMaxSizeValue, scheduledThreadPoolMaxSizeValue);
ActiveMQClient.setGlobalThreadPoolProperties(threadPoolMaxSizeValue, scheduledThreadPoolMaxSizeValue);
}
{code}
If either of these properties is not defined, thread pool sizes are not set on ActiveMQClient. User may want to set only one of these properties.
It seems that Artemis doesn't have API allowing configuration of single property.
Example:
# set global client thead pool max size using CLI - /subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=300)
# as the condition 'threadPoolMaxSizeValue != null && scheduledThreadPoolMaxSizeValue != null' is not satisfied (the other propery is undefined / null), set value 300 is not correctly configured on activemq.
https://github.com/wildfly/wildfly/blob/6c0a002da2558fd4e4f72ceb034a0633c...
was:
Logic in messaging integration doesn't allow configuring property {{global-client-thread-pool-max-size}} without setting {{global-client-scheduled-thread-pool-max-size}} and vice versa [1]. It seems that Artemis doesn't have API allowing configuration of single property.
User may want to set only one of these properties.
https://github.com/wildfly/wildfly/blob/6c0a002da2558fd4e4f72ceb034a0633c...
> Unable to set global-client-thread-pool-max-size without setting global-client-scheduled-thread-pool-max-size and vice versa
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10168
> URL: https://issues.jboss.org/browse/WFLY-10168
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
>
> Logic in messaging integration doesn't allow configuring property {{global-client-thread-pool-max-size}} without setting {{global-client-scheduled-thread-pool-max-size}} and vice versa [1].
> {code}
> if (threadPoolMaxSize.isDefined()) {
> threadPoolMaxSizeValue = GLOBAL_CLIENT_THREAD_POOL_MAX_SIZE.resolveModelAttribute(context, operation).asInt();
> } else if (sysprops.containsKey(THREAD_POOL_MAX_SIZE_PROPERTY_KEY)) {
> threadPoolMaxSizeValue = Integer.parseInt(sysprops.getProperty(THREAD_POOL_MAX_SIZE_PROPERTY_KEY));
> } else {
> // property is not configured using sysprop or explicit attribute
> threadPoolMaxSizeValue = null;
> }
> if (scheduledThreadPoolMaxSize.isDefined()) {
> scheduledThreadPoolMaxSizeValue = GLOBAL_CLIENT_SCHEDULED_THREAD_POOL_MAX_SIZE.resolveModelAttribute(context, operation).asInt();
> } else if (sysprops.containsKey(SCHEDULED_THREAD_POOL_SIZE_PROPERTY_KEY)) {
> scheduledThreadPoolMaxSizeValue = Integer.parseInt(sysprops.getProperty(SCHEDULED_THREAD_POOL_SIZE_PROPERTY_KEY));
> } else {
> // property is not configured using sysprop or explicit attribute
> scheduledThreadPoolMaxSizeValue = null;
> }
> if (threadPoolMaxSizeValue != null && scheduledThreadPoolMaxSizeValue != null) {
> MessagingLogger.ROOT_LOGGER.debugf("Setting global client thread pool size to: regular=%s, scheduled=%s", threadPoolMaxSizeValue, scheduledThreadPoolMaxSizeValue);
> ActiveMQClient.setGlobalThreadPoolProperties(threadPoolMaxSizeValue, scheduledThreadPoolMaxSizeValue);
> }
> {code}
> If either of these properties is not defined, thread pool sizes are not set on ActiveMQClient. User may want to set only one of these properties.
> It seems that Artemis doesn't have API allowing configuration of single property.
> Example:
> # set global client thead pool max size using CLI - /subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=300)
> # as the condition 'threadPoolMaxSizeValue != null && scheduledThreadPoolMaxSizeValue != null' is not satisfied (the other propery is undefined / null), set value 300 is not correctly configured on activemq.
> https://github.com/wildfly/wildfly/blob/6c0a002da2558fd4e4f72ceb034a0633c...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4104) Clear log
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4104?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-4104:
---------------------------------------
You could do this now like you suggest with changing the file name, then changing it back.
{code}
/subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file, value={relative-to=jboss.server.log.dir, path="server-new.log"})
/subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file, value={relative-to=jboss.server.log.dir, path="serve.log"})
{code}
You'll end up with two files so not ideal, but it will work.
One thing to consider too though is if there was a forced rotation the file rotated by the operation would get overridden and the logs lost on the next rotate.
> Clear log
> ---------
>
> Key: WFCORE-4104
> URL: https://issues.jboss.org/browse/WFCORE-4104
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Olivier Cailloux
> Assignee: James Perkins
> Priority: Minor
>
> When debugging it’s handy to be able to easily clear the log just before triggering an action that makes an application misbehave (so that you can then inspect the log knowing that it starts when the action starts).
> For this, it would be nice to have the possibility to force rotate the log on the periodic-rotating-file-handler type of handler.
> Thus we would run something like this in the CLI: /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name="rotate", value=true)
> Maybe it’s already possible by writing the "enabled" or "change-file" or "append" attribute (twice, to put it back to its previous state), but it feels hackish and it’s undocumented, therefore I’m not sure what the side effects of this would be (even assuming it would work).
> GlassFish for example has [asadmin rotate-log|https://github.com/oliviercailloux/java-course/blob/master/Gla...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2978) Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2978?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2978:
--------------------------------
Description:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules (/)
-- check rule can extend rule (/)
-- check dtable can extend rule (/)
-- No error in server log (/)
-- Convert to gdst (/)
was:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules (x)
-- check rule can extend rule (x)
-- check dtable can extend rule (x)
-- No error in server log (/)
-- Convert to gdst (/)
> Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
> ----------------------------------------------------------------------------
>
> Key: DROOLS-2978
> URL: https://issues.jboss.org/browse/DROOLS-2978
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.7.0.Final
> Environment: Red Hat Decision Manager 7.0.0
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools, support
> Attachments: repo.zip, rule-selection-in-EXPECTATION.png
>
>
> In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
> h2. Acceptance test
> - Upload valid XLSX
> -- Check scenarios see rules (/)
> -- check rule can extend rule (/)
> -- check dtable can extend rule (/)
> -- No error in server log (/)
> -- Convert to gdst (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4102) ModelPersistenceTestCase fails when running after ReadConfigAsFeaturesStandaloneTestCase
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4102?page=com.atlassian.jira.plugi... ]
Richard Janík commented on WFCORE-4102:
---------------------------------------
The issue is that the {{ReadConfigAsFeaturesStandaloneTestCase}} reloads the container with with a snapshot configuration file (e.g. {{20180911-141111004standalone.xml}}) and keeps using it - never reloads back to the default ({{standalone.xml}}).
The test {{ModelPersistenceTestCase}} expects the container uses a non-snapshot configuration file (e.g. {{standalone.xml}}). Files like the {{*.last.xml}} only seem to exist for non-snapshot configurations. I know next to nothing about this, so I'll assume this is all by design.
I'll submit a PR with a fix to {{ReadConfigAsFeaturesStandaloneTestCase}} in a few moments.
> ModelPersistenceTestCase fails when running after ReadConfigAsFeaturesStandaloneTestCase
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-4102
> URL: https://issues.jboss.org/browse/WFCORE-4102
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 6.0.1.Final
> Reporter: Jan Kalina
> Assignee: Richard Janík
>
> ModelPersistenceTestCase fails when ReadConfigAsFeaturesStandaloneTestCase runs in order before it.
> Not depending on JDK version - affects JDK 8,9,11.
> {code}
> [INFO] Running org.wildfly.core.test.standalone.mgmt.api.core.ReadConfigAsFeaturesStandaloneTestCase
> [INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.29 s - in org.wildfly.core.test.standalone.mgmt.api.core.ReadConfigAsFeaturesStandaloneTestCase
> [INFO] Running org.wildfly.core.test.standalone.mgmt.api.ModelPersistenceTestCase
> [ERROR] Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.088 s <<< FAILURE! - in org.wildfly.core.test.standalone.mgmt.api.ModelPersistenceTestCase
> [ERROR] testTakeAndDeleteSnapshot(org.wildfly.core.test.standalone.mgmt.api.ModelPersistenceTestCase) Time elapsed: 0.017 s <<< ERROR!
> java.io.FileNotFoundException: /home/jkalina/work/wildfly-core/testsuite/standalone/target/wildfly-core/standalone/configuration/standalone_xml_history/20180910-161302223standalone.last.xml (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.<init>(FileInputStream.java:138)
> at org.apache.commons.io.FileUtils.checksum(FileUtils.java:2873)
> at org.apache.commons.io.FileUtils.checksumCRC32(FileUtils.java:2846)
> at org.wildfly.core.test.standalone.mgmt.api.ModelPersistenceTestCase.testTakeAndDeleteSnapshot(ModelPersistenceTestCase.java:207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:109)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFWIP-78) Journal compacting doesn't work with JDK 11
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-78?page=com.atlassian.jira.plugin.s... ]
Martin Styk commented on WFWIP-78:
----------------------------------
This issue is valid also with Artemis 2.6 in current WF master (as of 11th September 2018).
> Journal compacting doesn't work with JDK 11
> -------------------------------------------
>
> Key: WFWIP-78
> URL: https://issues.jboss.org/browse/WFWIP-78
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Environment: {noformat}
> java 11-ea 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {noformat}
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Critical
> Labels: jdk10, jdk11
>
> Journal compacting doesn't work with Artemis 1.5 and JDK 11
> It fails with following stack trace:
> {noformat}
> 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
> at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: duplicate or slice
> at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
> {noformat}
> This causes issues also in scenario with journal replication.
> {noformat}
> 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (SWSQE-413) Checker Needs To 'Ping' Routes
by Matt Mahoney (JIRA)
Matt Mahoney created SWSQE-413:
----------------------------------
Summary: Checker Needs To 'Ping' Routes
Key: SWSQE-413
URL: https://issues.jboss.org/browse/SWSQE-413
Project: Kiali QE
Issue Type: QE Task
Reporter: Matt Mahoney
Assignee: Michael Foley
The 'Checker' script needs to ping routes to ensure applications are not only deployed, but also available to the user.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-10736:
---------------------------------------
[~pferraro] I've updated steps to reproduce. I've removed the workaround and 30 sec delay from the test. It will reproduce the issue and generate the traces. Could you run it with your build, please?
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Fix For: 15.0.0.Alpha1
>
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, Lodh2TestCase.testRemoteJcaInboundOnly2.zip, clusterKilTest.zip, logs-traces.zip, logs-traces2.zip, logs-traces3.zip, logs-traces4.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months