Hi Domenico, Will investigate your enhancement, could be the answer!
Thanks, Dave On Fri, Jul 23, 2021, 1:37 PM Domenico Francesco Bruscino, < bruscin...@gmail.com> wrote: > Hi David, > > it could be a timing issue, when a first client connects to a broker, it > sends a notification to other brokers of the cluster. So if a second client > with the same clienID connects to another broker of the cluster before it > receive the notification, the second broker accepts the connection. > > You could easily fix this issue by redirecting each client with the same > clientID to the same broker. > > Regards, > Domenico > > > On Fri, 23 Jul 2021 at 14:02, David Martin <dav...@qoritek.com> wrote: > > > Hi Domenico, > > > > OK thanks I'll have a look at that. > > > > Was considering writing a plugin to block authorisation when the same > > client ID is already connected elsewhere on the cluster, with leader > > election via a multicast queue. > > > > I'm puzzled why it's behaving this way though. It's not consistent. > Usually > > it prevents the double connection but on occasion it doesn't. > > > > > > > > Dave > > > > > > On Fri, 23 Jul 2021 at 10:48, Domenico Francesco Bruscino < > > bruscin...@gmail.com> wrote: > > > > > Hi Dave, > > > > > > I'm working on a new ActiveMQ Artemis feature that allows users to > > > balance incoming client connections according to their ClientID (or > other > > > connection parameters), see the draft documentation[2] for further > > details. > > > > > > [2] > > > > > > > > > https://github.com/brusdev/activemq-artemis/blob/broker_balancers/docs/user-manual/en/broker-balancers.md > > > > > > Regards, > > > Domenico > > > > > > On Fri, 23 Jul 2021 at 11:01, David Martin <dav...@qoritek.com> wrote: > > > > > > > Hi all, > > > > > > > > Puzzled by some behaviour we're seeing on a broker cluster of 3 live > > > > Artemis v2.16.0 brokers hosted on k8s which has an F5 in front of it > > > > terminating TLS and routing to a k8s node port forwarding to an AMQP > > > > acceptor for each broker. The cluster is healthy and has been up for > > > about > > > > 2 months without interruption. Each broker has its own storage. The > > > address > > > > routing is set up with redistribution delay = 0 and the clustering is > > > using > > > > all default settings and static discovery. > > > > > > > > Clients all use *non-shared* durable topic subscriptions via QPID JMS > > > v1.0. > > > > > > > > What we're seeing is that if two separate physical clients attempt to > > > open > > > > a connection using the same client ID, Artemis *occasionally* allows > > both > > > > to succeed and allows both to consume the durable subs on 2 different > > > > brokers. I thought this was only possible if round-robin routing was > > > > explicitly enabled on the clustering configuration by configuring > > STRICT > > > > message load balancing instead of the default ON_DEMAND. Of course, > due > > > to > > > > the F5, it will appear to Artemis that both clients are running on > the > > > same > > > > physical host. > > > > > > > > Is there some "belt and braces" way to prevent 2 connections with one > > > > client id in addition to the message load balancing configuration? > > > > > > > > > > > > Thanks, > > > > > > > > Dave > > > > > > > > > >
