[JBoss JIRA] (WFWIP-112) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Martyn Taylor (JIRA)
Martyn Taylor created WFWIP-112:
-----------------------------------
Summary: [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
Key: WFWIP-112
URL: https://issues.jboss.org/browse/WFWIP-112
Project: WildFly WIP
Issue Type: Bug
Components: JMS
Reporter: Martyn Taylor
Assignee: Martyn Taylor
Priority: Blocker
Having queue defined as follows
{code:xml}
<jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
{code}
Client is instantiating it directly using its name.
{code:title=Client}
HashMap<String, Object> map = new HashMap<String, Object>();
map.put("host", hostName);
map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
map.put("port", httpPort);
TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
try {
ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
connection = cf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(orderQueue);
connection.start();
...
{code}
Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
{code}
javax.jms.InvalidDestinationException: Destination InQueue does not exist
at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
{code}
This is regression against EAP 7.1.0
Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-111) JMSDesination and ReplyTo address contain different names to those set on sender
by Martyn Taylor (JIRA)
Martyn Taylor created WFWIP-111:
-----------------------------------
Summary: JMSDesination and ReplyTo address contain different names to those set on sender
Key: WFWIP-111
URL: https://issues.jboss.org/browse/WFWIP-111
Project: WildFly WIP
Issue Type: Bug
Components: Artemis, JMS
Reporter: Martyn Taylor
Assignee: Martyn Taylor
Priority: Blocker
The name of the JMSDestination (when using default producer destination) and ReplyTo addresses of a message do not match the consumed message. This looks to be cause be the adding of prefixes to the destination name before the messages are forwarded to the consumer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3965) Cover possible error when host controllers can not connect to domain after creating a rollout plan and restarting the master host controller
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3965?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek reopened WFCORE-3965:
-----------------------------------
There is a problem in test, when environment is not cleaned after execution (discovered in downstream)
> Cover possible error when host controllers can not connect to domain after creating a rollout plan and restarting the master host controller
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3965
> URL: https://issues.jboss.org/browse/WFCORE-3965
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Fix For: 6.0.0.Alpha5
>
>
> On downstream (6.4.x) there is an error https://bugzilla.redhat.com/show_bug.cgi?id=1599625 about error during restart of master host with rollout plan. This problem doesn't happen on master, but both fix and test should to be created also for wildfly (to satisfy upstream and prevent similar problems to happen - by introducing a test).
> Original problem:
> Creating a rollout plan and restarting the dc host prevent the other hosts to connect to the master again. The slave hc is unable to connect giving the error JBAS014687: Resource is immutable, the dc shows many errors like:
> JBAS012119: cancelled task by interrupting thread Thread[Host Controller Service Threads - 117,5,Host Controller Service Threads]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-72) Critical IO Error ... when starting Artemis with HA JDBC store
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-72?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak updated WFWIP-72:
--------------------------------
Labels: feature-branch-blocker (was: )
> Critical IO Error ... when starting Artemis with HA JDBC store
> --------------------------------------------------------------
>
> Key: WFWIP-72
> URL: https://issues.jboss.org/browse/WFWIP-72
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: log-node-1.zip
>
>
> One of the servers in collocated HA topology with JDBC store can fail on critical IO exception and stop itself.
> This was hit on Artemis 1.5.5.012 and WF: https://github.com/jmesnil/wildfly - WFLY-9513_messaging_jdbc_HA_shared-store branch.
> Test scenario:
> * Start 2 WF/EAP servers in collocated topology with Artemis HA JDBC store
> * Start client which are sending and consuming messages to/from queue from 1st server
> Result:
> There is intermittent failure when client start to send/receive messages on 1st server. 1st fails on Critical IO Error with exception:
> {code}
> 10:19:27,965 WARN [org.apache.activemq.artemis.journal] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ142021: Error on IO callback, null
> 10:19:27,965 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ222010: Critical IO Error, shutting down the server. file=org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile@407c5d8f, message=Error writing to JDBC file.: java.lang.NullPointerException
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:161) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:186) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.lambda$scheduleWrite$1(JDBCSequentialFile.java:197) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
> NPE happens at {{JDBCSequentialFile.internalWrite}} line 161:
> {code}
> private synchronized int internalWrite(byte[] data, IOCallback callback) {
> try {
> open();
> 161 synchronized (writeLock) { <-- NPE is thrown here
> ...
> {code}
> .
> Attaching logs from the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-110) [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
by Martyn Taylor (JIRA)
Martyn Taylor created WFWIP-110:
-----------------------------------
Summary: [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
Key: WFWIP-110
URL: https://issues.jboss.org/browse/WFWIP-110
Project: WildFly WIP
Issue Type: Bug
Components: Artemis
Reporter: Martyn Taylor
Assignee: Martyn Taylor
Priority: Blocker
There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
Test scenario:
* Start 2 server in Artemis cluster
* Start 2 servers with MDB connected to Artemis cluster
** MDB resends messages from InQueue to OutQueue from/to remote cluster
* Send messages to InQueue
* Restart all server (one by one)
* Consumes messages from OutQueue
Results:
After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3962) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3962?page=com.atlassian.jira.plugi... ]
Rostislav Svoboda commented on WFCORE-3962:
-------------------------------------------
{quote}
I think this is going to be best handled with documentation.
{quote}
I don't think so, this needs to be transparent to the end user as much as possible.
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3962
> URL: https://issues.jboss.org/browse/WFCORE-3962
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Modules, Scripts
> Affects Versions: 6.0.0.Alpha3
> Reporter: Matej Novotny
> Assignee: Richard Opalka
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> As per request, copying MODULES-372 to WFCORE as well.
> Starting WFLY with JDK 11 using {{standalone.sh}} yields:
> {code}
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> {code}
> Output of {{java -version}}:
> {code}
> openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+21)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-108) OpenTracing modules need jboss-api=private in module.xml
by Juraci Paixão Kröhling (JIRA)
[ https://issues.jboss.org/browse/WFWIP-108?page=com.atlassian.jira.plugin.... ]
Juraci Paixão Kröhling commented on WFWIP-108:
----------------------------------------------
The modules are:
org.eclipse.microprofile.opentracing
org.wildfly.microprofile.opentracing-smallrye
org.wildfly.extension.microprofile.opentracing
As the MP-Config one (org.eclipse.microprofile.config.api) does *not* specify this property, I'd like to confirm whether ours should indeed include it.
> OpenTracing modules need jboss-api=private in module.xml
> --------------------------------------------------------
>
> Key: WFWIP-108
> URL: https://issues.jboss.org/browse/WFWIP-108
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Request Tracing
> Reporter: Brian Stansberry
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
>
> The 3 modules added in https://github.com/wildfly/wildfly/pull/11454 need this in their module.xml:
> {code}
> <properties>
> <property name="jboss.api" value="private"/>
> </properties>
> {code}
> This ensures that we log a WARN if the user tries to _directly_ use these modules as application dependencies. (Directly == via their own deployment configuration, not via our subsystem wiring them in as a dependency. See [1] for the impl.)
> These log WARNs and the setting in the file itself are important both to prevent the user making mistakes and as the formal the mechanism by which we control how we support use of the various libraries we ship in the appserver. Marking modules private, deprecated etc gives us the freedom to rework implementations without worrying about breaking unexpected uses of things.
> [1] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-107) MP Health TCK have unexpected warnings
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-107?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda commented on WFWIP-107:
-----------------------------------------
Thanks, I created https://issues.jboss.org/browse/WFLY-10843 in the main tracker so it gets attention by wider team.
> MP Health TCK have unexpected warnings
> --------------------------------------
>
> Key: WFWIP-107
> URL: https://issues.jboss.org/browse/WFWIP-107
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
>
> When running MP Health TCK I see warnings in server log repeated for each test
> TCK are run via https://github.com/rsvoboda/wildfly-microprofile-health-tck
> warnings:
> {code}
> 13:26:23,101 WARN [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0012:
> Warning while parsing jar:file:/Users/rsvoboda/tmp/wildfly/dist/target/wildfly-14.0.0.Beta2-SNAPSHOT/modules/system/layers/base/io/smallrye/health/main/
> smallrye-health-1.0.2.jar!/META-INF/beans.xml:4 cvc-elt.1.a:
> Cannot find the declaration of element 'beans'.
> {code}
> {code}
> 13:26:23,169 WARN [org.jboss.modules.define] (Weld Thread Pool -- 8) Failed to define class org.eclipse.microprofile.health.tck.SingleProcedureSuccessfulTest in Module "deployment.tck.war" from Service Module Loader:
> java.lang.NoClassDefFoundError: Failed to link org/eclipse/microprofile/health/tck/SingleProcedureSuccessfulTest
> (Module "deployment.tck.war" from Service Module Loader): org/eclipse/microprofile/health/tck/SimpleHttp
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1009)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1088)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:519)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.as.weld@14.0.0.Beta2-SNAPSHOT//org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:82)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:62)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:108)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:87)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:55)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:52)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:844)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 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:
---------------------------------------
This is kill -9 and restart scenario.
It's affecting bare metal and cloud scenario as well. WF/EAP in pod is automatically restarted with the same node name when it's killed in Openshift.
I'll rerun the test with infinispan/jgroups traces. Do you have a specific WF branch you want to try or just WF master?
> 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: Radoslav Husar
> Priority: Blocker
> Labels: blocker-WF14
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly.zip, clusterKilTest.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, 11 months