[
https://issues.apache.org/jira/browse/ARTEMIS-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441454#comment-16441454
]
Justin Bertram commented on ARTEMIS-1285:
-----------------------------------------
I don't see any JGroups configuration details despite the fact that your
previous comment says they are "above."
Can you modify the "replicated-multiple-failover" example on your fork of the
Artemis repository to reproduce the failure in an automated way? It's generally
best to avoid manual testing, copy & pasting configs, etc. This should be a
pretty straight-forward process, and if we can get an automated reproducer it
will make identifying the issue much simpler in the long run.
Also, is there a specific reason you're using JGroups TCPPING here vs. just
using the simpler static connectors? JGroups integration was implemented mainly
for cloud-based use-cases where normal static connector configuration would be
tedious and unreliable and where UDP multicast was disabled.
> Standby slave would not announce replication to master when the slave is down
> -----------------------------------------------------------------------------
>
> Key: ARTEMIS-1285
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1285
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.1.0
> Reporter: yangwei
> Priority: Major
>
> We have a cluster of 3 instances: A is master, B is slave and C is standby
> slave. When slave is down, we expect C announces replication to A but A is in
> standalone mode all the time. We see C waits at "nodeLocator.locateNode()"
> through jstack command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
