It is entirely against the JMS spec requirements, and thus similarly non-portable, yes.
On Thu, 19 Sept 2024 at 11:57, <herbert.helmstr...@systema.com> wrote: > Hello Robbie. > > I have found a solution to set the client ID and use shared topics in > different clients at the same time. > The option > > connectionFactory.setEnableSharedClientID(*true*); > > does the trick. May it be against JMS spec or not, everything works fine. > > 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 18:42 > Betreff: [Ext] Re: Re: Re: Artemis ClientID and shared topics > ------------------------------ > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
