0

I'm using ActiveMQ Artemis cluster of 3 brokers (1 master, 2 slaves), setup with UDP broadcast.

ActiveMQ Artemis is starting as expected, but when trying create JMS connections using SAG webMethods it returns the error:

clientID=activemq was already set into another connection

I have 3 Integration servers, each configured with this JNDI config, pointing to 3 ActiveMQ Artemis brokers:

  • Initial Context Factory: org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
  • Provider URL: tcp://S1:9000?sslEnabled=true&ha=true&reconnectAttempts=-1
  • Provider URL Failover List: tcp://S2:9000?sslEnabled=true,tcp://S3:9000?sslEnabled=true

I need to connect my T1, T2 and T3 webmethods servers to the ActiveMQ Artemis cluster. On T1 server, I manage to establish JMS connection with activemq as clientID. But on remaining T2 and T3 webmethods servers, the error clientID=activemq was already set into another connection is returned.

ActiveMQ Artemis supports JMS 2.0 and multiple clients pointing to same clientID/destination should be possible right? It allows shared subscription.

What I'm missing here? I do not created any topic at all, I only want to establish the JMS connections on 3 servers first.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
José Oliveira
  • 1

1 Answers1

0

ActiveMQ Artemis does support JMS 2.0 and therefore shared durable subscriptions, but section 6.1.2 of the JMS 2 specification states:

The purpose of client identifier is to associate a connection and its objects with a state maintained on behalf of the client by a provider. By definition, the client state identified by a client identifier can be ‘in use’ by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.

...

The only use of a client identifier defined by JMS is its mandatory use in identifying an unshared durable subscription or its optional use in identifying a shared durable or non-durable subscription. [emphasis mine]

Therefore, the reason you're getting the exception is because you're attempting to violate the JMS specification. Please set a unique client identifier for each durable subscriber or simply omit the client identifier if you're using a shared durable subscription.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
  • Hi Justin, thanks for your response. I'm using a shared durable subscriber, I want the events to be processed once by 1 of the 3 nodes. If I only provide the clientId at 1/3 JMS connections, the trigger using this destination does not start at the connections without clientId: Cannot create durable subscription - client ID has not been set Is it possible to define clientId on connection factory, reusing clientID on the 3 JMS connections? I need the 3 connections listening If so, do you know where I need to change? On the JNDI provider URL? Broker.xml? artemis.profile? Thank you! – José Oliveira Apr 21 '20 at 09:20
  • What API call are you using to create the shared durable subscription? As noted in my answer, the client ID is mandatory for an unshared durable subscription but *optional* for a shared durable subscription. It sounds like you're using an API call which is creating an unshared durable subscription. – Justin Bertram Apr 21 '20 at 13:59
  • It's the webmethods integration server that using the API behind the scenes...and we are suspecting they use it the same way as on their internal messaging component, and therefore calling a wrong API that does not fully support JMS 2.0. The only way to check is decompiling the product libs.... – José Oliveira Apr 21 '20 at 16:34
  • If the application isn't calling the proper JMS 2.0 method then you won't be able to share a subscription among multiple consumers. That feature is only supported in JMS 2.0. For what it's worth, this is another good reason to use Open Source software - you can just look and see exactly what it's doing. – Justin Bertram Apr 21 '20 at 16:41