[
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)
