Hi Cian- Heads up— Artemis has been spun out into its own project (November 2025) and has its own mailing list, issue tracker, etc.
For Artemis questions, sending your question to those lists is your best bet. Thanks, Matt Pavlovich Apache ActiveMQ PMC > On Sep 28, 2026, at 10:39 AM, Larkin, Cian via users > <[email protected]> wrote: > > We're running a 3-node Artemis cluster (replicated, Kubernetes/EKS) behind > ingress-nginx, with a single shared hostname for client connections > (SSL-passthrough on the AMQP/Core port). We're seeing significant > consumer-connection imbalance across brokers — e.g. 300 consumer connections > landing as ~150/75/75 instead of ~100/100/100 — which is causing consumption > slowness on the overloaded broker. > Root cause we've identified: SSL-passthrough bypasses nginx's own > load-balancer entirely , so the actual "which broker" decision is made once, > at connect time, by kube-proxy — and once a connection lands, it's sticky for > its lifetime with no rebalancing. Any broker restart/rollout produces a > fresh, uncorrected skew that compounds over time. > We evaluated: > > * <connection-router> — redirects new connections round-robin, but our > client library only follows a redirect on retry, not on the very first > connection attempt (confirmed still true on current mainline > ClientSessionFactoryImpl/ActiveMQClientProtocolManager). > * useTopologyForLoadBalancing — redirects to internal pod hostnames > unreachable from outside the cluster in our ingress setup. > * Static multi-connector + RoundRobinConnectionLoadBalancingPolicy — > works, but is client-side only and doesn't rebalance existing connections > after a scale event. > > Question for the community: has anyone solved this at the broker/client level > rather than the infra level? Specifically — is there any roadmap/plan for the > client library to follow a connection-router redirect on the first connection > attempt (not just retries)? That would make <connection-router> viable for > our use case. Or is there a recommended pattern for exposing an Artemis > cluster behind a single shared external hostname that we're missing? > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
