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
Von: "Robbie Gemmell" <[email protected]>
An: [email protected]
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, <[email protected]> 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
> [email protected]
>
> 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" <[email protected]>
> An: [email protected]
> 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, <[email protected]> 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
> > [email protected]
> >
> > 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" <[email protected]>
> > An: [email protected]
> > Kopie: [email protected]
> > 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, <[email protected]> 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
> > > [email protected]
> > >
> > > 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.
> > >
> > >
> >
> >
> >
> >
>
>
>
>
