[
https://issues.apache.org/jira/browse/ARTEMIS-4325?focusedWorklogId=867160&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-867160
]
ASF GitHub Bot logged work on ARTEMIS-4325:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jun/23 13:16
Start Date: 23/Jun/23 13:16
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4522:
URL:
https://github.com/apache/activemq-artemis/pull/4522#issuecomment-1604273061
I had the same thought about using the topology update to know when the
"original" node came back. I think that would be simpler than manually checking
and it would save a thread as well.
Issue Time Tracking
-------------------
Worklog Id: (was: 867160)
Time Spent: 0.5h (was: 20m)
> Ability for core client to failback after failover
> --------------------------------------------------
>
> Key: ARTEMIS-4325
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4325
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Anton Roskvist
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This would be similar to the "priorityBackup" functionality in ActiveMQ
> "Classic."
> The primary use case for this is to more easily maintain a good distribution
> of consumers and producers across a broker cluster over time.
> The intended behavior for my own purposes would be something like:
> * Ensure an even distribution across the broker cluster when first connecting
> a high throughput client.
> * When a broker becomes unavailable (network outage, patch, crash, whatever),
> move affected client workers to another broker in the cluster to maintain
> throughput.
> * When the original broker comes back, move the recently failed-over
> resources to the original broker again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
