[ https://issues.apache.org/jira/browse/ARTEMIS-4325?focusedWorklogId=867156&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-867156 ]
ASF GitHub Bot logged work on ARTEMIS-4325: ------------------------------------------- Author: ASF GitHub Bot Created on: 23/Jun/23 12:55 Start Date: 23/Jun/23 12:55 Worklog Time Spent: 10m Work Description: brusdev commented on PR #4522: URL: https://github.com/apache/activemq-artemis/pull/4522#issuecomment-1604244307 This feature makes sense to me if your are not using HA (live/backup pairs), have you already considered waiting for a topology update to know when a node is up? https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java#L1567 Issue Time Tracking ------------------- Worklog Id: (was: 867156) Time Spent: 20m (was: 10m) > 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: 20m > 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)