[ https://issues.apache.org/jira/browse/ARTEMIS-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798943#comment-17798943 ]
Gary Tully commented on ARTEMIS-4545: ------------------------------------- the peer activation allows the node id to be set, it is named as the correlation id but is actually the node id. see: [https://github.com/apache/activemq-artemis/blob/main/tests/smoke-tests/src/main/resources/servers/zkReplicationPrimaryPeerA/broker.xml#L42] not sure if that helps your use case, but a peer activation with a ha file lock, say on a shared volume with tight tolerance, could be a good approach. at the moment, I don't think the file lock can be on a different volume from the journal, but if it could, we could have a mostly reliable file lock on a shared directory, with only the locking taking the sync and reliable read/lock hit. > Allow node ID to be configured > ------------------------------ > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature > Reporter: Justin Bertram > Assignee: Justin Bertram > Priority: Major > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010)