Your opinion regarding "obtaining JMS Queue directly from JMS QueueSession using Netty connection only and no JNDI"

[refon]

In J2EE context (JBOSS AS), while trying to streamline JMS configurations using

remote Netty connection factory I have successfully replaced JNDI calls to obtain

JMS Queue by using queueSession.createQueue() as follow:

(...)

// Obtain the request queue directly from the session

Queue requestQ = queueSession.createQueue("myQueueName");

// Create queue sender

QueueSender myQueueSender = queueSession.createSender(requestQ);

// Send the message

myQueueSender.send(message);

(...)

To me the benefit seems twofold:

1. Remote HornetQ connections can be achieve using Netty with no remote JNDI calls. For instance a HornetQ JMS client within a JBOSS AS 5.1.0 patched with HornetQ 2.2.5.Final can dialog with HornetQ JMS server withing JBOSS AS 6.1.0.Final or JBOSS AS 7.0.2.Final JMS servers (all of them using HornetQ 2.2.5.Final)
2. Queue will benefit of any Netty defined connection behaviour such as client reconnection, automatic discovery,...

I'd be interested in your opinion regarding the above.

Patrick

[ataylor]

im not sure if you will see any difference, the best way would be to map it as a resource, i think you can do this even with remote jndi, or if you have hornetq running locally too simply define it there and use local jndi i.e.

@Resource("queuName")

Queue q;

altho i cant remember the exact syntax

[refon]

Dear Andy thank you for your feedback, I am happy to read you think I shall not see any difference (in performance I guess), and agree it would be better to map JMS Queue as resource. But put simply, I could achieve accessing local JMS Queue as resource using the following syntax:

@Resource(mappedName = "queue/myQueueName")

Queue myQueueName;

but did not find a way (configuration or syntax...) to achieve this for remote JMS Queues!

On the other hand I was able to access a remotely located ConnectionFactory using properly defined HornetQ and JMS datasource configurations (using netty) and the following syntax:

@Resource(mappedName = "java:/MyRemoteJmsXA")

ConnectionFactory connectionFactory;

Then I worked around not obtaining the remote Queue resource by using:

queueSession.createQueue("myQueueName");

where the queueSession is obtained throught queueConnection itself obtained from the remote connectionFactory.

[clebert.suconic]

To lookuop the queue: I don't remember the method name now.. but there is a createQueue method on the javax.jms.Session that will create the queue object.

JNDI is a bit overkill as it's using a lot of serialization. It's always best to create the object directly.

[refon]

Dear Clebert thank you for pointing out avoiding JNDI is positive with regards to performances.

Could it be that the "lookup queue" method you think about is also the "createQueue" method you mention:

javax.jms.Session.createQueue(String queueName)

Or do I overlook the difference between queue look up and queue identity creation ?

Indeed to me, this Session.createQueue() method name was missleading until I finally read the Javadoc:

public Queue createQueue(String queueName) throws JMSException

Creates a queue identity given a Queue name.

This facility is provided for the rare cases where clients need to dynamically manipulate queue identity. It allows the creation of a queue identity with a provider-specific name. Clients that depend on this ability are not portable.

Note that this method is not for creating the physical queue. The physical creation of queues is an administrative task and is not to be initiated by the JMS API. The one exception is the creation of temporary queues, which is accomplished with the createTemporaryQueue method.
(...)

Full Javadoc ref.: http://download.oracle.com/javaee/1.4/api/javax/jms/Session.html#createQueue%28java.lang.String%29