Using (IronJacamar) Resource Adapter for HornetQ

[b.eckenfels]

Hello,

in AS7 HornetQ has it own pooled resource adpater configuration for the /JmsXA connection factory. However I have the problem, that I would also like to cache connections in a remote application server.

So I have 2 types of application servers, one is running the HornetQ messaging subsystem and exporting a connection factory (lets call this CENTRAL). Multiple leightweight applications servers without the messagig subsystem use the remote JNDI access to those exported factories. This works fine, but I have now make my own session pooling.

My idea was now to use the IronJacamar ressource adapter in the NODE applications servers and configure it to wrap the client implementation of the remote JMS client. Is this possible with configuration?

(There are two reasons we would like to avoid the JMS subsystem in those NODE application servers, one is footprint/dependencies and the other is the ability for heterogenous versions in the landscape).

Gruss

Bernd

[jbertram]

It is technically possible to deploy the HornetQ JCA RA without the messaging subsystem.  To get the RA you can do one of the following:

• Download a 2.2.x distribution and use the lib/hornetq-ra.rar
• Download a 2.3.x distribution and build the RA using the examples/jms/hornetq-ra-rar
• Pull the desired release from https://github.com/hornetq/hornetq/tags and build it that way

Please note that client compatibility with HornetQ is very good so even old client versions won't have a problem with newer servers.

Once you've got the RA you can using the Iron Jacamar RAR info tool to generate a sample AS7 deployment descriptor and then add that to your standalone*.xml or domain.xml.

The only issue I think you'll have is that the HornetQ JCA RA doesn't support any admin objects for binding HornetQ JMS destinations in the local JNDI namespace (https://issues.jboss.org/browse/HORNETQ-908).  However, you can work around this by using the JMS API javax.jms.Session.createQueue(String).  If you choose this route keep in mind that the String passed to createQueue will be the underlying HornetQ name of the destination, not the JNDI entry.