EAP7: Artemis RA vs AMQ 7 - provide more detailed description of the configuration

Latest response

the EAP 7(.1) document Configuring Messaging, chapter 31.3. Configuring the Artemis Resource Adapter to Connect to Red Hat JBoss AMQ 7 doesn't cover much detail for more advanced scenarios. For example:

  1. For most of additional connection properties, it's theoretically possible to specify them at 2 places:
  • on the pooled connection factory, e.g.
  • as additional parameters in the URL (java.naming.provider.url) in the external-context bindings, e.g.
java.naming.provider.url = tcp://localhost:61616?retryInterval=1000

I suppose the connection factory should be the primary target of such advanced configuration. However how about the java.naming.provider.url in the external-context bindings? If that URL should be configured in such way as well It would be good to somehow cover that. At least in the form of a brief mention with the link pointing to the appropriate place.

  1. (dummy entry to correct the numbering)

  2. Similarly, if I want to specify multiple brokers to connect to (cluster), how it should be done? Again I expect that using multiple connectors by the connection factory is the thing to do, however should these multiple brokers be actually configured at both places (pooled-connection-factory & java.naming.provider.url)? Or AMQ user+password?

  3. Minor glitch/inconsistency: in "3. Add a pooled connection factory for the remote connector." the CLI example created a connection factory named activemq-ra-remote, however the XML example that follows shows its name being remote-artemis.

  4. In the same paragraph "3. Add a pooled connection factory for the remote connector." the space delimited specification of multiple JNDI names: entries=[java:/RemoteJmsXA java:jboss/RemoteJmsXA] leads to a little weird behavior at EAP 7.1 - the connection factory is bound under the name "java:/RemoteJmsXA java:jboss/RemoteJmsXA" instead of those 2 names separately. If comma is used as a delimiter then this doesn't happen.

Note: There are many those connection properties, starting with clientID, ha, retryInterval and many others that can be found for example here:

The pooled connection factory advanced settings are somewhat documented (above linked A.3. Pooled Connection Factory Attributes ), however if the URL (java.naming.provider.url) should be configured in a similar manner as well, then these advanced properties should be documented somwhere. At least in a brief form with links to the Artemis documentation or so.


Hi Petr,

Thank you so much for taking the time to provide such valuable feedback about the documentation. Your thoroughness and attention to detail make it very easy for me to understand the issues you describe.

I have created this JIRA to address your concerns: https://issues.jboss.org/browse/JBEAP-14862

Feel free to add yourself as a watcher so you can track its progress.

Once again, thank you for letting us know about problems with the Configuration Messaging documentation. I really appreciate it as the goal is to make the documentation as useful as possible for our customers.

Hi Petr,

thanks for the valuable points. You've correctly pointed out that connection factories can be configured in pooled-connection-factory and external-context (Artemis allows it). However using external-context for creating connection factories is unsupported in EAP 7. Only pooled-connection-factory can be used for this purpose. External context is here just to create JMS destinations (queues/topics) on remote AMQ 7 broker and for registering those objects to JNDI tree of EAP 7 server so local deployments can inject them.

I'll try to explain a little deeper why creation of connection factory using external context is not supported. There is difference between connection factory created using pooled-connection-factory and external-context. If external-context is used to create connection factory by providing correct properties then it creates simple JMS connection factory as defined in JMS spec. It's equal to RemoteConnectionFactory which is defined by default in messaging-activemq subsystem. This connection factory does not know and use other components from application server (like transaction manager or security manager) and is independent from it. Connections created from this connection factory are not pooled and operation on them cannot be part of XA transaction which is managed by transaction manager (or at least it's hard to do so).

On the other side connection factory which is created from pooled-connection-factory is using features provided by application server and is highly recommended to be used in JavaEE depployments (EJB, Servlets, MDBs). Connections created from it are pooled (JCA - IronJacamar is doing that) and operations on connections can be part of XA transactions. It's much better integrated into application server.

This will be clarified in the documentation with the other points you've mentioned.

To the 2nd point. Once connection is created to any AMQ 7 broker,

Thanks, Mirek

Hello, thanks for replying. However it seems that part of Your response is missing.

As for the connection factory vs. external-context - I can imagine why it's this way, even though it looks a little strange.

The main question is whether any additional settings (connection properties related to authentication, SSL, high availability) should be set for both connection definitions.

After doing some (limited) trials it seems that for example user authentication isn't required on the external-context connection. However for instance high availability or SSL related settings might be required there as well, because for example initial connection against the cluster would fail if there would be just 1 AMQ server defined in the URL and that one would be inaccessible at the time of the connection attempt etc.

On the other hand performance related settings aren't probably very important for the external-context connection since that isn't used for transferring messages etc.

Right, thanks for pointing this out. For some reason 2nd part got lost.

It's important to know that once first connection is created to AMQ 7 broker, cluster topology of AMQ 7 brokers is updated on EAP 7/Artemis RA side. New connections are then automatically load-balanced to all AMQ 7 nodes in cluster. The important thing here is that AMQ 7 brokers must be in cluster. Of course it's better provide more connectors to pooled-connection-factory so if any of the AMQ 7 cluster nodes is down then it can still try another connector to create the first connection.

External context is quite similar in this. It's necessary to provide URLs to all nodes in cluster so at least one will succeed. It also tries URLs in round-robin fashion.

I cannot answer for sure whether SSL is required on both. I would say yes but I've never tried it. Two way or one way SSL authentication can be configured by configuring keystore and truststore on acceptor on AMQ7 broker. Then any incoming connection to this acceptor must go through SSL authentication. This means that SSL keystore/trustore must be configured on connector used by pooled-connection-factory and in external context as well.