[
https://issues.apache.org/jira/browse/ARTEMIS-5925?focusedWorklogId=1007724&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1007724
]
ASF GitHub Bot logged work on ARTEMIS-5925:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 03/Mar/26 17:02
Start Date: 03/Mar/26 17:02
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #6268:
URL: https://github.com/apache/artemis/pull/6268#discussion_r2879412295
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/BrokerConnection.java:
##########
@@ -32,6 +33,16 @@ default void shutdown() throws Exception {
// Subclass should override and perform needed cleanup.
}
+ LockCoordinator getLockCoordinator();
+
+ BrokerConnection setLockCoordinator(LockCoordinator lockCoordinator);
+
+
+ /** return true is active, false if paused */
+ boolean isActive();
+
+ BrokerConnection setActive(boolean active);
Review Comment:
Its not generally a good idea to expose a toggle for internally managed
state to the outside world. It leads to issues where code toggles state that
might have never been tested to handle and it enforces more work on the
implementation to handle not only the internal state transitions but also
account for external code toggling state that probably shouldn't be alterable
from outside the component. This is not currently used outside the AMQP broker
connection component so I'd say we don't expose it on this interface until we
have a valid reason to.
##########
docs/user-manual/lock-coordination.adoc:
##########
@@ -5,38 +5,39 @@
The Lock Coordinator 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.
+This prevents split-brain scenarios where multiple brokers could
simultaneously process messages, leading to duplicate processing or conflicting
state.
-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:
-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.
+* *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 the 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.
+* *Broker Connections* - When a broker connection (AMQP mirror, federation, or
bridge) is associated with a lock coordinator, it will only be active when the
broker successfully acquires the distributed lock. If the lock is lost, the
connection is paused, preventing message flow. When the lock is reacquired, the
connection resumes automatically.
+
+The same pattern used on acceptors and broker connections 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.
WARNING: This feature is in technical preview and its configuration elements
are subject to possible modifications.
== 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.
+You can define multiple lock-coordinators and associate them with broker
elements such as acceptors and broker connections.
+When a broker element is associated with a lock-coordinator, it will only
activate when the distributed lock can be acquired.
Review Comment:
Suggested change: "it will only activate when the distributed lock has been
acquired"
Issue Time Tracking
-------------------
Worklog Id: (was: 1007724)
Time Spent: 4.5h (was: 4h 20m)
> Support Star Mirror Configuration on Lock Coordinator
> -----------------------------------------------------
>
> Key: ARTEMIS-5925
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5925
> Project: Artemis
> Issue Type: Improvement
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.53.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The Lock Coordinator should be applied to Broker Connections.
> Notice that broker connection should also be made, however mirroring should
> not be capturing events while "paused". This is to guarantee past mirror
> events would be sent after a reconnect. StarMirrorSingleAcceptorRunningTest
> shows the need for this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
