Hi Tim, I get your point but they are third parties.
I understand the problem will have to write a plug-in I think.. Dave On Fri, Jul 23, 2021, 10:08 PM Tim Bain, <tb...@alumni.duke.edu> wrote: > 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 > > > > > > > > > > > > > > >
