JMS 1 says that the named durable subscriptions are ClientID-scoped, you needed a ClientID to use a named durable subscription (in practice many JMS 1 implementations did let you omit explicitly configuring a ClientID, so long as you didnt try to use a durable subscription). It also says a given ClientID can only be used by 1 Connection at a time. JMS 2 had to retain those behaviours since full API compatibility was an aim, i.e only adding new APIs and related behaviours.
I was not involved in JMS 2 so I can only speculate that they probably decided to apply the 'if ClientID set, subscription is ClientID-scoped' behaviour for both shared and non-shared subscriptions to continue the prior behaviour and be consistent in that regard between the non-shared and shared durable sub cases, and maybe to aid implementation, since they also made non-shared and shared durable subscriptions both use the same/existing ClientID-scoped namespace when a ClientID is set. However, ClientID was also made expressly optional in JMS2, and when using the new shared subscriptions behave such that there is a new distinct subscription space for users who might want to share durable subscriptions across different no-ClientID Connections at the same time. The non-durable shared subscriptions similarly also have their own distinct spaces, with ClientID-scope + without. On Mon, 9 Sept 2024 at 13:51, <herbert.helmstr...@systema.com> wrote: > 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 > > ------------------------------ > > *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: "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. > > > > > > > > > > > > > > > > > >
