Possibility of Split brain in ActiveMQ Artemis HA shared storage?

What are the possibilities of split brain in Artemis HA shared storage deployment? ActiveMQ Artemis 2.17.0 is deployed as HA active/passive with shared storage in AWS EFS. Any specific log statements to check in artemis.log?

master cluster configuration

    <connectors>
       <connector name="artemis">tcp://<master_ip>:61616</connector>
       <connector name="discovery-connector">tcp://<slave_ip>:61616</connector>
    </connectors>
    
    <cluster-connections>
       <cluster-connection name="artemis_cluster_configuration">
          <connector-ref>artemis</connector-ref>
          <message-load-balancing>ON_DEMAND</message-load-balancing>
    			
          <max-hops>1</max-hops>
          <static-connectors>   
             <connector-ref>discovery-connector</connector-ref> 
          </static-connectors> 
       </cluster-connection>
    </cluster-connections>
    
    
    <ha-policy>
       <shared-store>
          <master>
             <failover-on-shutdown>true</failover-on-shutdown>
          </master>
       </shared-store>
    </ha-policy>

slave cluster configuration

    <connectors>
       <connector name="artemis">tcp://<slave_ip>:61616</connector>
       <connector name="discovery-connector">tcp://<master_ip>:61616</connector>
    </connectors>
    
    <cluster-connections>
       <cluster-connection name="artemis_cluster_configuration">
          <connector-ref>artemis</connector-ref>
          <message-load-balancing>ON_DEMAND</message-load-balancing>
          <max-hops>1</max-hops>
          <static-connectors>   
             <connector-ref>discovery-connector</connector-ref> 
          </static-connectors> 
       </cluster-connection>
    </cluster-connections>
    
    
    <ha-policy>
       <shared-store>
          <slave>
             <failover-on-shutdown>true</failover-on-shutdown>
             <allow-failback>true</allow-failback>
          </slave>
       </shared-store>
    </ha-policy>

Generally speaking, shared storage is resilient against split-brain. I believe the only issue related to shared storage and split-brain which has been fixed since 2.17.0 is ARTEMIS-4143 which deals with the primary broker becoming disconnected from the shared storage and then reconnecting after the backup has already become active.

If you are using a discovery-group in your broker.xml then if you encounter split-brain you'll likely see a WARN log message with a code of AMQ212034 that says:

There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID={}

That said, I'm not certain about the locking semantics of AWS EFS. ActiveMQ Artemis shared storage was designed to run on a SAN or NAS filesystem that supports exclusive file locks (e.g. NFSv4). If AWS EFS supports that then it should be fine. Otherwise it won't work properly and both brokers are likely to be active simultaneously (i.e. encounter split-brain).