[
https://issues.apache.org/jira/browse/ARTEMIS-5852?focusedWorklogId=1002346&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1002346
]
ASF GitHub Bot logged work on ARTEMIS-5852:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jan/26 21:16
Start Date: 28/Jan/26 21:16
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #6191:
URL: https://github.com/apache/artemis/pull/6191#discussion_r2738642035
##########
docs/user-manual/lock-cordination.adoc:
##########
@@ -0,0 +1,159 @@
+= Lock Coordination
+:idprefix:
+:idseparator: -
+:docinfo: shared
+
+The Lock Manager provides pluggable distributed lock mechanism monitoring.
+It allows multiple broker instances to coordinate the activation of specific
configuration elements, ensuring that only one broker instance activates a
particular element at any given time.
+
+When a broker acquires a lock through a distributed lock, the associated
configuration elements are activated.
+If the lock is lost or released, those elements are deactivated.
+
+In the current version, the Lock Coordinator can be applied to control the
startup and shutdown of acceptors.
+When an acceptor is associated with a lock coordinator, it will only start
accepting connections when the broker successfully acquires the distributed
lock.
+If lock is lost for any reason, the acceptor automatically stops accepting new
connections.
+
+The same pattern used on acceptors may eventually be applied to other
configuration elements.
+If you have ideas for additional use cases where this pattern could be
applied, please file a JIRA issue.
+
+== Configuration
+
+It is possible to specify multiple lock-coordinators and associate them with
other broker elements.
+
+The broker element associated with a lock-coordinator (e.g., an acceptor) will
only be started if the distributed lock can be acquired.
+If the lock cannot be acquired or is lost, the associated element will be
stopped.
+
+This pattern can be used to ensure clients connect to only one of your
mirrored brokers at a time, preventing split-brain scenarios and duplicate
message processing.
+
+Depending on the provider selector, multiple configuration options can be
provided.
+Please consult the javadoc for your lock implementation.
+A simple table will be provided in this chapter for the two reference
implementations we provide, but this could be a plugin being added to your
broker.
+
+In this next example, we configure a broker with:
+
+* Two acceptors: one for mirroring traffic (`for-mirroring-only`) and one for
client connections (`for-clients-only`)
+* A ZooKeeper-based lock-coordinator named `clients-lock`
+* The client acceptor associated with the lock-coordinator, so it only
activates when the distributed lock is acquired
+* A mirror connection to another broker for data replication
+
+[,xml]
+----
+<acceptors>
+ <acceptor
name="for-mirroring-only">tcp://0.0.0.0:61001?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>
+ <acceptor name="for-clients-only"
lock-coordinator="clients-lock">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>
+</acceptors>
+
+<lock-coordinators>
+ <lock-coordinator name="clients-lock">
+ <type>file</type>
+ <lock-id>mirror-cluster-clients</lock-id>
+ <check-period>1000</check-period> <!
Issue Time Tracking
-------------------
Worklog Id: (was: 1002346)
Time Spent: 3h 10m (was: 3h)
> Leader/Follower pattern on acceptors
> ------------------------------------
>
> Key: ARTEMIS-5852
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5852
> Project: Artemis
> Issue Type: New Feature
> Components: Broker
> Affects Versions: 2.50.0
> Reporter: Clebert Suconic
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.51.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> This opens the possibility of using Mirroring for Failover, in replacement of
> replication.
> You set a LeaderManager on the configuration, and configure Acceptors to only
> start after a distributed lock is acquired.
> this current implementation is being done on top of DistributedLockManager,
> and I'm adding etcd as an option also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
