[
https://issues.apache.org/jira/browse/ARTEMIS-5925?focusedWorklogId=1007561&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1007561
]
ASF GitHub Bot logged work on ARTEMIS-5925:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 02/Mar/26 23:20
Start Date: 02/Mar/26 23:20
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #6268:
URL: https://github.com/apache/artemis/pull/6268#discussion_r2875189902
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java:
##########
@@ -251,7 +276,20 @@ public synchronized void initialize() throws Exception {
}
@Override
- public synchronized void start() throws Exception {
+ public void start() throws Exception {
+
+ if (lockCoordinator != null) {
+ this.active = false;
+ // this needs to be started before the acceptor, hence a lower
priority on start
+ lockCoordinator.onLockAcquired(this::resume, 5);
Review Comment:
These priority values seem arbitrary and very difficult to correlate amongst
any future things that also need some specific priority settings. I'd
recommend at least creating some defined group values like PRIORITY_GROUP_A etc
that get run in order, where you could even use the same priority for both
entries and reverse sort for the released state. Having to search through
every usage to try and figure out what priority to set is not particularly
maintainable over time.
Issue Time Tracking
-------------------
Worklog Id: (was: 1007561)
Time Spent: 1.5h (was: 1h 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: 1.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]
