[JBoss JIRA] (WFLY-13136) Can't create a Polled Connection Factory using Jgroups
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13136?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-13136:
-------------------------------------
Description:
When trying to configure a pooled connection factory with a JGroup Discovery Group it fails withg the exception:
{noformat}
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0412: Required services that are not installed:" => ["jboss.messaging-activemq.bindings.discovery.dg-group1"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.jms.pooled-connection-factory.activemq-ra is missing [jboss.messaging-activemq.bindings.discovery.dg-group1]"]
},
"rolled-back" => true
}
{noformat}
Reproducer:
- start in full-ha
{code:java}
/subsystem=messaging-activemq/discovery-group=dg-group1:add(initial-wait-timeout=30000, jgroups-channel=ee, jgroups-cluster=artemis-cluster)
/subsystem=messaging-activemq/pooled-connection-factory=activemq-ra:add(transaction=xa, entries=[java:/JmsXA, java:jboss/DefaultJMSConnectionFactory],discovery-group=dg-group1)
{code}
was:
When trying to configure a pooled connection factory with a JGroup Discovery Group it fails withg the exception:
Reproducer:
- start in full-ha
Create dg
/subsystem=messaging-activemq/discovery-group=dg-group1:add(initial-wait-timeout=30000, jgroups-channel=ee, jgroups-cluster=artemis-cluster)
/subsystem=messaging-activemq/pooled-connection-factory=activemq-ra:add(transaction=xa, entries=[java:/JmsXA, java:jboss/DefaultJMSConnectionFactory],discovery-group=dg-group1)
> Can't create a Polled Connection Factory using Jgroups
> ------------------------------------------------------
>
> Key: WFLY-13136
> URL: https://issues.redhat.com/browse/WFLY-13136
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 19.0.0.Beta2
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> When trying to configure a pooled connection factory with a JGroup Discovery Group it fails withg the exception:
> {noformat}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.messaging-activemq.bindings.discovery.dg-group1"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.jms.pooled-connection-factory.activemq-ra is missing [jboss.messaging-activemq.bindings.discovery.dg-group1]"]
> },
> "rolled-back" => true
> }
> {noformat}
> Reproducer:
> - start in full-ha
> {code:java}
> /subsystem=messaging-activemq/discovery-group=dg-group1:add(initial-wait-timeout=30000, jgroups-channel=ee, jgroups-cluster=artemis-cluster)
> /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra:add(transaction=xa, entries=[java:/JmsXA, java:jboss/DefaultJMSConnectionFactory],discovery-group=dg-group1)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13136) Can't create a Polled Connection Factory using Jgroups
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13136?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-13136:
-------------------------------------
Priority: Critical (was: Major)
> Can't create a Polled Connection Factory using Jgroups
> ------------------------------------------------------
>
> Key: WFLY-13136
> URL: https://issues.redhat.com/browse/WFLY-13136
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 19.0.0.Beta2
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> When trying to configure a pooled connection factory with a JGroup Discovery Group it fails withg the exception:
> {noformat}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.messaging-activemq.bindings.discovery.dg-group1"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.jms.pooled-connection-factory.activemq-ra is missing [jboss.messaging-activemq.bindings.discovery.dg-group1]"]
> },
> "rolled-back" => true
> }
> {noformat}
> Reproducer:
> - start in full-ha
> {code:java}
> /subsystem=messaging-activemq/discovery-group=dg-group1:add(initial-wait-timeout=30000, jgroups-channel=ee, jgroups-cluster=artemis-cluster)
> /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra:add(transaction=xa, entries=[java:/JmsXA, java:jboss/DefaultJMSConnectionFactory],discovery-group=dg-group1)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13136) Can't create a Polled Connection Factory using Jgroups
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13136:
----------------------------------------
Summary: Can't create a Polled Connection Factory using Jgroups
Key: WFLY-13136
URL: https://issues.redhat.com/browse/WFLY-13136
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 19.0.0.Beta2
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
When trying to configure a pooled connection factory with a JGroup Discovery Group it fails withg the exception:
Reproducer:
- start in full-ha
Create dg
/subsystem=messaging-activemq/discovery-group=dg-group1:add(initial-wait-timeout=30000, jgroups-channel=ee, jgroups-cluster=artemis-cluster)
/subsystem=messaging-activemq/pooled-connection-factory=activemq-ra:add(transaction=xa, entries=[java:/JmsXA, java:jboss/DefaultJMSConnectionFactory],discovery-group=dg-group1)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ]
James Perkins commented on WFCORE-3376:
---------------------------------------
I went ahead and removed the fix version for this. The RFE EAP7-1420 is in a state which could potentially become stalled which would require a different approach for this fix. Until those decisions are made we should not commit to a release.
> Modules may create loggers on a deployments log context
> -------------------------------------------------------
>
> Key: WFCORE-3376
> URL: https://issues.redhat.com/browse/WFCORE-3376
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
>
> Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader.
> What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-3376:
----------------------------------
Fix Version/s: (was: 11.0.0.Beta10)
> Modules may create loggers on a deployments log context
> -------------------------------------------------------
>
> Key: WFCORE-3376
> URL: https://issues.redhat.com/browse/WFCORE-3376
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
>
> Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader.
> What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2452) UFC_NB/MFC_NB: blocks
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2452?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2452 at 2/19/20 10:46 AM:
----------------------------------------------------------
{{Credit}} (UFC), {{NonBlockingCredit}} (UFC_NB), {{CreditMap}} (MFC) and {{NonBlockingCreditMap} (MFC_NB) now have a {{done}} field, which identifies a credit which should not be used any longer. This means, all threads are released and new threads never block, but just fall through.
{{done}} is set via {{reset()}}.
Unit tests added for all 3 cases above.
Also need unit tests for the protocols ({{UFC}}, {{UFC_NB}}, {{MFC}}) themselves
was (Author: belaban):
{{Credit}} (UFC), {{NonBlockingCredit}} (UFC_NB) and {{CreditMap}} (MFC) now have a {{done}} field, which identifies a credit which should not be used any longer. This means, all threads are released and new threads never block, but just fall through.
{{done}} is set via {{reset()}}.
Unit tests added for all 3 cases above.
Also need unit tests for the protocols ({{UFC}}, {{UFC_NB}}, {{MFC}}) themselves
> UFC_NB/MFC_NB: blocks
> ---------------------
>
> Key: JGRP-2452
> URL: https://issues.redhat.com/browse/JGRP-2452
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> Despite having full credits and {{queuing==false}}, we have a sender thread blocking (see below).
> This can happen when a thread is queueing; when we stop the member, or a new view is installed, {{queueing}} is never set to false and the thread is never unblocked!
> {noformat}
> "jgroups-830,ma267mlvjdg021" #1394 prio=5 os_prio=0 tid=0x0000000004442000 nid=0x307c waiting on condition [0x00007fbda44be000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000005f2189da0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at org.jgroups.util.SizeBoundedQueue.add(SizeBoundedQueue.java:51)
> at org.jgroups.util.NonBlockingCredit.addToQueue(NonBlockingCredit.java:98)
> at org.jgroups.util.NonBlockingCredit.decrementIfEnoughCredits(NonBlockingCredit.java:58)
> at org.jgroups.protocols.UFC_NB.handleDownMessage(UFC_NB.java:87)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:315)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:309)
> at org.jgroups.protocols.FRAG3.down(FRAG3.java:145)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:914)
> at org.jgroups.JChannel.down(JChannel.java:677)
> at org.jgroups.JChannel.send(JChannel.java:516)
> at org.jgroups.protocols.relay.Route.send(Route.java:42)
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:572)
> at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:425)
> at org.jgroups.stack.Protocol.down(Protocol.java:317)
> at org.jgroups.fork.ForkProtocol.down(ForkProtocol.java:42)
> at org.jgroups.fork.ForkProtocolStack.down(ForkProtocolStack.java:62)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:222)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:21)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.send(JGroupsTransport.java:1041)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendCommand(JGroupsTransport.java:998)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.backupRemotely(JGroupsTransport.java:329)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeXSite(RpcManagerImpl.java:414)
> at org.infinispan.xsite.BackupSenderImpl.backupCommand(BackupSenderImpl.java:250)
> at org.infinispan.xsite.BackupSenderImpl.backupWrite(BackupSenderImpl.java:201)
> at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor.handleSingleKeyWriteReturn(NonTransactionalBackupInterceptor.java:144)
> at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor$$Lambda$655/1680487200.accept(Unknown Source)
> at org.infinispan.interceptors.InvocationSuccessAction.apply(InvocationSuccessAction.java:22)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:118)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30)
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102)
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1361)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1264)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$300(JGroupsTransport.java:127)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.up(JGroupsTransport.java:1425)
> at org.jgroups.JChannel.up(JChannel.java:816)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> at org.jgroups.stack.Protocol.up(Protocol.java:339)
> at org.jgroups.protocols.FORK.up(FORK.java:142)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:452)
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:872)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1008)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:734)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:389)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:590)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:280)
> at org.jgroups.protocols.Discovery.up(Discovery.java:295)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1250)
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2452) UFC_NB/MFC_NB: blocks
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2452?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2452:
--------------------------------
{{Credit}} (UFC), {{NonBlockingCredit}} (UFC_NB) and {{CreditMap}} (MFC) now have a {{done}} field, which identifies a credit which should not be used any longer. This means, all threads are released and new threads never block, but just fall through.
{{done}} is set via {{reset()}}.
Unit tests added for all 3 cases above.
Also need unit tests for the protocols ({{UFC}}, {{UFC_NB}}, {{MFC}}) themselves
> UFC_NB/MFC_NB: blocks
> ---------------------
>
> Key: JGRP-2452
> URL: https://issues.redhat.com/browse/JGRP-2452
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> Despite having full credits and {{queuing==false}}, we have a sender thread blocking (see below).
> This can happen when a thread is queueing; when we stop the member, or a new view is installed, {{queueing}} is never set to false and the thread is never unblocked!
> {noformat}
> "jgroups-830,ma267mlvjdg021" #1394 prio=5 os_prio=0 tid=0x0000000004442000 nid=0x307c waiting on condition [0x00007fbda44be000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000005f2189da0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at org.jgroups.util.SizeBoundedQueue.add(SizeBoundedQueue.java:51)
> at org.jgroups.util.NonBlockingCredit.addToQueue(NonBlockingCredit.java:98)
> at org.jgroups.util.NonBlockingCredit.decrementIfEnoughCredits(NonBlockingCredit.java:58)
> at org.jgroups.protocols.UFC_NB.handleDownMessage(UFC_NB.java:87)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:315)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:309)
> at org.jgroups.protocols.FRAG3.down(FRAG3.java:145)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:914)
> at org.jgroups.JChannel.down(JChannel.java:677)
> at org.jgroups.JChannel.send(JChannel.java:516)
> at org.jgroups.protocols.relay.Route.send(Route.java:42)
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:572)
> at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:425)
> at org.jgroups.stack.Protocol.down(Protocol.java:317)
> at org.jgroups.fork.ForkProtocol.down(ForkProtocol.java:42)
> at org.jgroups.fork.ForkProtocolStack.down(ForkProtocolStack.java:62)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:222)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:21)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.send(JGroupsTransport.java:1041)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendCommand(JGroupsTransport.java:998)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.backupRemotely(JGroupsTransport.java:329)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeXSite(RpcManagerImpl.java:414)
> at org.infinispan.xsite.BackupSenderImpl.backupCommand(BackupSenderImpl.java:250)
> at org.infinispan.xsite.BackupSenderImpl.backupWrite(BackupSenderImpl.java:201)
> at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor.handleSingleKeyWriteReturn(NonTransactionalBackupInterceptor.java:144)
> at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor$$Lambda$655/1680487200.accept(Unknown Source)
> at org.infinispan.interceptors.InvocationSuccessAction.apply(InvocationSuccessAction.java:22)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:118)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30)
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102)
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1361)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1264)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$300(JGroupsTransport.java:127)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.up(JGroupsTransport.java:1425)
> at org.jgroups.JChannel.up(JChannel.java:816)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> at org.jgroups.stack.Protocol.up(Protocol.java:339)
> at org.jgroups.protocols.FORK.up(FORK.java:142)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:452)
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:872)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1008)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:734)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:389)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:590)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:280)
> at org.jgroups.protocols.Discovery.up(Discovery.java:295)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1250)
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months