[
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)