August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2838) Avoid using readAccessor in alpha network compiler

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2838?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2838: ---------------------------------- Sprint: 2018 Week 30-32 (was: 2018 Week 30-32, 2018 Week 33-35) > Avoid using readAccessor in alpha network compiler > -------------------------------------------------- > > Key: DROOLS-2838 > URL: https://issues.jboss.org/browse/DROOLS-2838 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Luca Molteni > > Alpha Network compiler should be limited to the executable model so that we can avoid using the readAccessor and use a LambdaAccessor instead -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10872) Missing translation for writing simple-load-provider attribute in mod_cluster subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10872: ------------------------------------- Lowering priority, as this is not a bug, but rather needs a better error message. > Missing translation for writing simple-load-provider attribute in mod_cluster subsystem > --------------------------------------------------------------------------------------- > > Key: WFLY-10872 > URL: https://issues.jboss.org/browse/WFLY-10872 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Paul Ferraro > > Following should add simple load provider with factor=0: > {code} > /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0) > {code} > Instead, this error shows up: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"modcluster\"), > (\"proxy\" => \"default\"), > (\"load-provider\" => \"simple\") > ]' not found", > "rolled-back" => true > } > {code} > There is missing translation to create the resource, same is the situation for undefine operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10872) Missing translation for writing simple-load-provider attribute in mod_cluster subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-10872: -------------------------------- Priority: Major (was: Blocker) > Missing translation for writing simple-load-provider attribute in mod_cluster subsystem > --------------------------------------------------------------------------------------- > > Key: WFLY-10872 > URL: https://issues.jboss.org/browse/WFLY-10872 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Paul Ferraro > > Following should add simple load provider with factor=0: > {code} > /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0) > {code} > Instead, this error shows up: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"modcluster\"), > (\"proxy\" => \"default\"), > (\"load-provider\" => \"simple\") > ]' not found", > "rolled-back" => true > } > {code} > There is missing translation to create the resource, same is the situation for undefine operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10888) Opentracing CDI extension is using deprecated method leading to WARN

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-10888?page=com.atlassian.jira.plugin... ] Matej Novotny updated WFLY-10888: --------------------------------- Description: Opentracing [CDI extension|https://github.com/wildfly/wildfly/blob/master/microprofile/ope...] which registers bean types is using deprecated method which leads to WARNINGs every time it is registered. {code} 2018-08-20 12:24:43,009 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-3) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.wildfly.microprofile.opentracing.smallrye.TracerProducer is deprecated from CDI 1.1! 2018-08-20 12:24:43,010 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-3) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class io.smallrye.opentracing.SmallRyeTracingCDIInterceptor is deprecated from CDI 1.1! {code} Instead of [{{BBD.addAnnotatedType(AnnotatedType<?> type)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/jav...] you should be using [{{BBD.addAnnotatedType(AnnotatedType<?> type, String id)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax...]. Will send PR shortly. was: Opentracing [CDI extension|https://github.com/wildfly/wildfly/blob/master/microprofile/ope...] which registers bean types is using deprecated method which leads to WARNINGs every time it is registered. Instead of [{{BBD.addAnnotatedType(AnnotatedType<?> type)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/jav...] you should be using [{{BBD.addAnnotatedType(AnnotatedType<?> type, String id)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax...]. Will send PR shortly. > Opentracing CDI extension is using deprecated method leading to WARN > -------------------------------------------------------------------- > > Key: WFLY-10888 > URL: https://issues.jboss.org/browse/WFLY-10888 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 14.0.0.Beta2 > Reporter: Matej Novotny > Assignee: Matej Novotny > > Opentracing [CDI extension|https://github.com/wildfly/wildfly/blob/master/microprofile/ope...] which registers bean types is using deprecated method which leads to WARNINGs every time it is registered. > {code} > 2018-08-20 12:24:43,009 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-3) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.wildfly.microprofile.opentracing.smallrye.TracerProducer is deprecated from CDI 1.1! > 2018-08-20 12:24:43,010 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-3) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class io.smallrye.opentracing.SmallRyeTracingCDIInterceptor is deprecated from CDI 1.1! > {code} > Instead of [{{BBD.addAnnotatedType(AnnotatedType<?> type)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/jav...] you should be using [{{BBD.addAnnotatedType(AnnotatedType<?> type, String id)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax...]. > Will send PR shortly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10872) Missing translation for writing simple-load-provider attribute in mod_cluster subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ] Paul Ferraro edited comment on WFLY-10872 at 8/20/18 10:13 AM: --------------------------------------------------------------- The reason this fails is because there is only 1 load provider allowed at a given time, and the current load provider is the dynamic one. Consequently, the existing load provider needs to be removed first (adding the load-provider=simple will also do this). The error message is admittedly confusing, since the operation executed is not the same as the one entered, meaning: /subsystem=mod_cluster/mod-cluster-config=configuration:write-attribute(name=simple-load-provider, value=0) will actually execute: /subsystem=mod_cluster/mod-cluster-config=configuration/load-provider=simple:write-attribute(name=factor, value=0) What we should do is validate the existence of the load-provider=simple resource first and use a more contextual message rather than the current one. was (Author: pferraro): The reason this fails is because there is only 1 load provider allowed at a given time, and the current load provider is the dynamic one. Consequently, the existing load provider needs to be removed first. The error message is admittedly confusing, since the operation executed is not the same as the one entered, meaning: /subsystem=mod_cluster/mod-cluster-config=configuration:write-attribute(name=simple-load-provider, value=0) will actually execute: /subsystem=mod_cluster/mod-cluster-config=configuration/load-provider=simple:write-attribute(name=factor, value=0) What we should do is validate the existence of the load-provider=simple resource first and use a more contextual message rather than the current one. > Missing translation for writing simple-load-provider attribute in mod_cluster subsystem > --------------------------------------------------------------------------------------- > > Key: WFLY-10872 > URL: https://issues.jboss.org/browse/WFLY-10872 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Paul Ferraro > Priority: Blocker > > Following should add simple load provider with factor=0: > {code} > /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0) > {code} > Instead, this error shows up: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"modcluster\"), > (\"proxy\" => \"default\"), > (\"load-provider\" => \"simple\") > ]' not found", > "rolled-back" => true > } > {code} > There is missing translation to create the resource, same is the situation for undefine operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10872) Missing translation for writing simple-load-provider attribute in mod_cluster subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10872: ------------------------------------- The reason this fails is because there is only 1 load provider allowed at a given time, and the current load provider is the dynamic one. Consequently, the existing load provider needs to be removed first. The error message is admittedly confusing, since the operation executed is not the same as the one entered, meaning: /subsystem=mod_cluster/mod-cluster-config=configuration:write-attribute(name=simple-load-provider, value=0) will actually execute: /subsystem=mod_cluster/mod-cluster-config=configuration/load-provider=simple:write-attribute(name=factor, value=0) What we should do is validate the existence of the load-provider=simple resource first and use a more contextual message rather than the current one. > Missing translation for writing simple-load-provider attribute in mod_cluster subsystem > --------------------------------------------------------------------------------------- > > Key: WFLY-10872 > URL: https://issues.jboss.org/browse/WFLY-10872 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Paul Ferraro > Priority: Blocker > > Following should add simple load provider with factor=0: > {code} > /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0) > {code} > Instead, this error shows up: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"modcluster\"), > (\"proxy\" => \"default\"), > (\"load-provider\" => \"simple\") > ]' not found", > "rolled-back" => true > } > {code} > There is missing translation to create the resource, same is the situation for undefine operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10888) Opentracing CDI extension is using deprecated method leading to WARN

by Matej Novotny (JIRA)

Matej Novotny created WFLY-10888: ------------------------------------ Summary: Opentracing CDI extension is using deprecated method leading to WARN Key: WFLY-10888 URL: https://issues.jboss.org/browse/WFLY-10888 Project: WildFly Issue Type: Bug Components: MP OpenTracing Affects Versions: 14.0.0.Beta2 Reporter: Matej Novotny Assignee: Matej Novotny Opentracing [CDI extension|https://github.com/wildfly/wildfly/blob/master/microprofile/ope...] which registers bean types is using deprecated method which leads to WARNINGs every time it is registered. Instead of [{{BBD.addAnnotatedType(AnnotatedType<?> type)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/jav...] you should be using [{{BBD.addAnnotatedType(AnnotatedType<?> type, String id)}}|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax...]. Will send PR shortly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3905) Improve SuspendController code

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3905?page=com.atlassian.jira.plugi... ] Yeray Borges reassigned WFCORE-3905: ------------------------------------ Assignee: Yeray Borges (was: Jeff Mesnil) > Improve SuspendController code > ------------------------------ > > Key: WFCORE-3905 > URL: https://issues.jboss.org/browse/WFCORE-3905 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jeff Mesnil > Assignee: Yeray Borges > Priority: Minor > > From Brians's comment at https://github.com/wildfly/wildfly-core/pull/3336#pullrequestreview-12543...: > bq. Reviewing this I see a few issues in SuspendController. 1) The Timer allocated at L98 is pointless unless timeoutMillis > 0. 2) The timeout() method can be private (same with activityPaused()). 3) The logging at L74-L78 is incorrect if timeoutMillis == 0. The "suspendingServerWithNoTimeout" message is not correct in that case as 'no timeout' doesn't mean '0 ms'. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10438) Create a domain testsuite smoke test for a missing host-exclude

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-10438?page=com.atlassian.jira.plugin... ] Yeray Borges reassigned WFLY-10438: ----------------------------------- Assignee: Yeray Borges (was: Jeff Mesnil) > Create a domain testsuite smoke test for a missing host-exclude > --------------------------------------------------------------- > > Key: WFLY-10438 > URL: https://issues.jboss.org/browse/WFLY-10438 > Project: WildFly > Issue Type: Task > Components: Management, Test Suite > Reporter: Brian Stansberry > Assignee: Yeray Borges > Labels: domain-mode > > We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources. > I had a complicated slow approach in mind that I wrote here before; it's stricken out below. > Much simpler approach: > Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions. Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version. > If we add a new extension and don't host-exclude it, this will fail. This really is all that's needed to avoid completely skipping the host-excludes. > If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail. This will help ensure the test isn't completely unmaintained. > It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful. > Original complicated approach: > -We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension. > Something like: > Base domain config must be the standard one we ship. It will include all extensions. > Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version. > Slave host.xml has 1 server only, and in that server group. > Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ] Jean-Frederic Clere reassigned WFLY-10736: ------------------------------------------ Assignee: Paul Ferraro (was: Radoslav Husar) > 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 > Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018