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?
