Hi Robbie, thank you for coming in on that. Yes shared topics are specified as seen seen in JMS2. Bad for us. Why the clientID is needed in this context stays an unsolved mystery. The subsctiptionId (in other products called groupName) should be enough, right? But changing that is up to a later version of JMS.
No matter - our customer wants to see, what application is connected to what broker. The ClientID would be great for that and the application name etc. is available. The ClientID is forced to be equal for collaborating instances with shared topics. This is acceptable, because the connections have a different ID in their own right. Is there somewhere specified, that the ClientIDs have to be unique system wide? I didn't find a place and I doubt this is really possible. Leaving them all null is in fact "all equal", the opposite of unique ... Best Regards Herbert Von: "Robbie Gemmell" <robbie.gemm...@gmail.com> An: users@activemq.apache.org Datum: 09.09.2024 12:16 Betreff: [Ext] Re: Re: Artemis ClientID and shared topics JMS 2 essentially outlined that shared named subscriptions on Connections with a ClientID are still ClientID-scoped (i.e can only be shared from that Connection), just as the existing non-shared named durable subscriptions were in JMS already. Additionally, JMS 2 also let you have shared named subscriptions on Connections without a ClientID, that could be shared with consumers on other similar Connections without a ClientID. This was how JMS 2 defined things ~12 years ago and so that is how things implementing it now work. The result of the JMS 2 additions was that there are 5 different effective topic subscription scopes/spaces (4 named, 1 not), and you can't access subscriptions in them all at the same time on the same Connection, since accessing some subs requires it has a specific ClientID, and others require that it does not. Personally, I would have considered a boolean arg on the new shared sub methods that indicated whether to scope the named shared subscription to the ClientID or not, but that is not what happened. On Fri, 6 Sept 2024 at 15:24, <herbert.helmstr...@systema.com> wrote: > Hi Domenico, > > Thank you for pointing me there. > the spec says in other words the clients must have no id if they want to > use shared topics. > Or they have the same Client ID which means the use the same connection, > because every connection needs a unique clientID witch can be tested quite > easily. > > javax.jms.InvalidClientIDException: clientID=SystemaServer was already > set into another connection > at > org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:265) > at > org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:654) > at > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:949) > > This really makes no sense. It may well be according to the spec, but it > reduces usability. It forces us to not use the clieant ID, if we want > shared topics accross application instances. > > Best Regards > > Herbert > > > ------------------------------ > > *Herbert Helmstreit* > Senior Software Engineer > > Phone: +49 941 / 7 83 92 36 > herbert.helmstr...@systema.com > > www.systema.com > > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/ >[image: > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: XING] > <https://www.xing.com/pages/systemagmbh> > > SYSTEMA > Systementwicklung Dipl.-Inf. Manfred Austen GmbH > > Manfred-von-Ardenne-Ring 6 | 01099 Dresden > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO > > P Please check whether a printout of this e-mail is really necessary. > > > > > Von: "Domenico Francesco Bruscino" <bruscin...@gmail.com> > An: users@activemq.apache.org > Kopie: maximilian.rie...@systema.com > Datum: 06.09.2024 15:37 > Betreff: [Ext] Re: Artemis ClientID and shared topics > ------------------------------ > > > > Hi Herbert, > > ActiveMQArtemis seems compliant with the JMS specifications: > > https://docs.oracle.com/javaee%2F7%2Fapi%2F%2F/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String- > A shared non-durable subscription is identified by a name specified by the > client and by the client identifier (which may be unset). > > Regards, > Domenico > > On Fri, 6 Sept 2024 at 11:50, <herbert.helmstr...@systema.com> wrote: > > > Hello Community! > > > > I am using the Artemis 2.33 Java JMS Core libraries. > > Whenever I set a clientID (via ConnectionFactory or Connection directly > > that makes no difference) > > the shared topic listener on these connections are broken. > > Instead of 1 of N consumers triggered by a message, N of N are triggered > > (normal topic listener reaction). > > The shared consumers are created like this: > > consumer = (ActiveMQMessageConsumer) > > session.createSharedConsumer(topic, getGroupName()+listenerName); > > The groupname is the unique name of the cooperating application instances > > and the listenerName is > > nearly equal the topicName. This construction is used to allow more than > > one shared topic in the group. > > If no clientID is set, it works fine. What has the clientID to do with > > shared topics anyway? > > I know in JMS1.1 durable subscribers needed it as reference. But this > does > > not apply here. > > Can anybody give a hint, what might be wrong? > > > > Kind Regards > > > > Herbert > > > > ------------------------------ > > > > *Herbert Helmstreit* > > Senior Software Engineer > > > > Phone: +49 941 / 7 83 92 36 > > herbert.helmstr...@systema.com > > > > www.systema.com > > > > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/ > >[image: > > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: XING] > > <https://www.xing.com/pages/systemagmbh> > > > > SYSTEMA > > Systementwicklung Dipl.-Inf. Manfred Austen GmbH > > > > Manfred-von-Ardenne-Ring 6 | 01099 Dresden > > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 > > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO > > > > P Please check whether a printout of this e-mail is really necessary. > > > > > > > >
