ARTEMIS-5925 Support Star Mirror Configuration on Lock Coordinator#6268
ARTEMIS-5925 Support Star Mirror Configuration on Lock Coordinator#6268clebertsuconic wants to merge 1 commit intoapache:mainfrom
Conversation
|
@tabish121 I need your help defining what pause / resume would means on Bridge / Federations. In Mirror should mean everything is connected but we are not capturing events.. To allow previous events to flow even if the mirror is paused (say right after a failure). |
...c/main/java/org/apache/activemq/artemis/protocol/amqp/connect/bridge/AMQPBridgeManagers.java
Outdated
Show resolved
Hide resolved
...c/main/java/org/apache/activemq/artemis/protocol/amqp/connect/federation/AMQPFederation.java
Outdated
Show resolved
Hide resolved
.../java/org/apache/activemq/artemis/protocol/amqp/connect/federation/AMQPFederationSource.java
Outdated
Show resolved
Hide resolved
...ol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java
Show resolved
Hide resolved
...ol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java
Show resolved
Hide resolved
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/BrokerConnection.java
Show resolved
Hide resolved
clebertsuconic
force-pushed
the
ARTEMIS-5925
branch
from
dcb47c6 to
1c9f770
Compare
|
all I need to do before setting ready to review is to add tests to parse the XML... and change documentation.. I will finish it shortly. I know there's some checkstyle issues, which I will also fix. |
clebertsuconic
force-pushed
the
ARTEMIS-5925
branch
2 times, most recently
from
cdaa39c to
4993631
Compare
Disclaimer: The test StarMirrorSingleAcceptorRunningTest was written with the help from Claude agent. I basically asked Claude to copy it from DualMirrorSingleAcceptorRunning with the additional configuration options.
clebertsuconic
force-pushed
the
ARTEMIS-5925
branch
from
4993631 to
3fd9e18
Compare
| 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); |
There was a problem hiding this 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.
2 participants
Disclaimer: The test StarMirrorSingleAcceptorRunningTest was written with the help from Claude agent. I basically asked Claude to copy it from DualMirrorSingleAcceptorRunning with the additional configuration options.