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" <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.
> > >
> > >
> >
> >
> >
> >
>
>
>
>




Reply via email to