Maybe I'm oversimplifying this, but isn't the client required to use a unique client ID, and we're splitting hairs over the exact undefined behavior that occurs when something invalid is done? It seems like the real solution is to modify the client applications to make them use unique client IDs, not to try to fine-tune the race conditions of the broker's attempt to handle the client's bug a little more gracefully...
Tim On Fri, Jul 23, 2021, 6:37 AM 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 > > > > > > > > > >
