[timfox]

henk de boer wrote:

Tim Fox wrote:

I still don't really understand what the problem is, so it's hard for me to provide a solution

I think the question is simply about re-creating the exact same object locally that you would normally get when you execute the following code:

I don't understand what you mean "locally".

The object you get from HornetQJMSClient.createQueue is *exactly* the same as the object you'd get from looking up the HornetQ destination in JNDI.

[timfox]

henk de boer wrote:

Where session is a session created from a connection to a remote HornetQ server and destination is created locally in a cheap and lightweight way, without any JNDI (caching or not), EJB, Java EE, JCA, or whatever involved.

I already said that HornetQJMSClient.createQueue() does not do any server side stuff. It's as lightweight as it comes

[timfox]

John Waterwood wrote:

Maybe others want to use server to connect to remote hornetQ. 
I just mean Java SE client. I want to create the simple address wrapper. You first said we could use HornetQJMSClient.createQueue for this, but this seems to have 2 problems: 1. It does more than creating simple wrapper only (this is problem for me),

Where did you come to that conclusion? - it DOES NOT do anything server side. A destination in HornetQ, as I have already said on this thread, is simply a unique id to the queue that lives on the server. It's basically just a string.

If you want to get a reference to a queue or topic but don't want to use JNDI, you can use this. This is exactly what it was designed for in the first place.

Now, if there is some other requirement that it does not solve, that part I do not yet understand. If someone can explain that in a concise and unambiguous way I can attempt to answer that.

[henk53]

Tim Fox wrote:

henk de boer wrote:

I think the question is simply about re-creating the exact same object locally that you would normally get when you execute the following code:

I don't understand what you mean "locally".

Well, with "locally" I mean the situation where you have any kind of code (Java SE, Java EE or even an applet if that's possible) that runs in JVM A. The HornetQ server then runs in JVM B, which you would thus call "remote".

Normally if you want to send anything to a queue that already exists in the already running remote HornetQ server, you would retrieve this queue via a JNDI lookup.

Now if you would re-create this object locally, then you would well, instantiate it in the local JVM without any kind of remoting (JNDI, RMI, raw TCP/IP sockets, whatever) to the already running HornetQ server.

It would be as-if you could just do:

MessageProducer producer = session.createProducer("jms.queue.a.someQueue");

Tim Fox wrote:

The object you get from HornetQJMSClient.createQueue is *exactly* the same as the object you'd get from looking up the HornetQ destination in JNDI.

As John remarked, the example at section 7.5 of the manual (http://hornetq.sourceforge.net/docs/hornetq-2.1.0.Final/user-manual/en/html/using-jms.html#d0e1186), seems to indicate that it not only retrieves a reference to an existing already deployed and operational queue, but also actually creates a queue, registers it with the post office, etc.

Or does the following:

Queue orderQueue = HornetQJMSClient.createQueue("OrderQueue");

assumes that there's already a queue called "OrderQueue" operational and deployed? If that's the case then I can understand the confusion. HornetQJMSClient.createQueue() would then indeed all that's needed and John's hunch is wrong (although it would perhaps be good to mention this in the manual then).

Does createQueue only returns a new HornetQQueue or does it try to locate a myriad of services and do various registrations on these services?

I guess the best way to find out is to just download the source code for HornetQ and inspect the HornetQJMSClient.createQueue code

[timfox]

henk de boer wrote:

As John remarked, the example at section 7.5 of the manual (http://hornetq.sourceforge.net/docs/hornetq-2.1.0.Final/user-manual/en/html/using-jms.html#d0e1186), seems to indicate that it not only retrieves a reference to an existing already deployed and operational queue, but also actually creates a queue, registers it with the post office, etc.

That is not correct. It does nothing of the sort. As I have said a few times on this thread now, it simply creates a local object which is basically just an identifier for the server side queue.

henk de boer wrote:

I guess the best way to find out is to just download the source code for HornetQ and inspect the HornetQJMSClient.createQueue code

You can take my word for it. I wrote the code and also wrote that example.

if you don't believe me feel free to look at the source.

[henk53]

Tim Fox wrote:

You can take my word for it. I wrote the code and also wrote that example.

if you don't believe me feel free to look at the source.

Of course I -believe- you. I encountered your name on top of many of the source files I read (both JBM and now HornetQ), and all of that code looks very good and very professional, so it goes without saying that you know absolutely what you're talking about

The only thing I meant with looking in the code was to verify that we're talking about the same thing

[john.waterwoodx]

Guys, I'm sorry for causing any confusion. I took Tim's "doesn't do anything on the server" for "you can't use this method when in Java EE (a server)"
. again sorry, this my mistake. Tim meant, "it does not contact any server".
Obviously, English is not first language for everyone.
Tims last remark about a local object which is basically an identifier for server side queue sounds very good. This is precisely what I need.
I will shut up now and go back to do coding ;-)

[atijms]

Wow, that's some discussion here going on

Thanks for all the replies everyone, I understand much better now how it all comes together.

John Waterwood wrote:

Now I'm very confused. Maybe just new HornetQQueue("jms.queue.selectorQueue"); is the simple solution everybody is looking for?

I'm not on HornetQ yet, but on the previous version (JBM) I tried the equivalent of new HornetQQueue():

InitialContext context = new InitialContext();
QueueConnectionFactory factory = (QueueConnectionFactory)context.lookup("java:/MyJmsXA");
QueueConnection connect = factory.createQueueConnection();
            
QueueSession session = connect.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

// Original version - looks up Destination from remote server
// Destination destination = (Destination)new InitialContext(env).lookup("/queue/myQueue");

// New version - creates Destination local            
Destination destination = new JBossQueue("myQueue");
            
MessageProducer sender = session.createProducer(destination);
            
ObjectMessage message = session.createTextMessage("test");
sender.send(message);

This works perfectly!

java:/MyJmsXA is a local JCA connection factory in a local JBoss AS 5.1 instance that caches connections for a remote connection factory from a second JBoss AS 5.1 instance.

My entire goal here was to have good performance for messaging and this seems to do the trick nicely. I'm still a bit in the dark how the connection pooling of the bisocket connector actually influences or interacts with the highler level JMS connection pooling in JBM, but as Tim mentioned this is an issue with the previous version of HornetQ (JBM). The current version uses Netty and a quick glance at it seems to reveal it doesn't uses a connection pool of its own.

Btw, after studying the JBM/HornetQ docs I think though that using a bridge is even better for overall performance, as it batches up many acknowledges in a single commit and permanantly re-uses a single connection, session and producer.

[ataylor]

My entire goal here was to have good performance for messaging and this seems to do the trick nicely. I'm still a bit in the dark how the connection pooling of the bisocket connector actually influences or interacts with the highler level JMS connection pooling in JBM, but as Tim mentioned this is an issue with the previous version of HornetQ (JBM). The current version uses Netty and a quick glance at it seems to reveal it doesn't uses a connection pool of its own.

Using the JmsXA connection factory will still use HornetQ factories under the cover. The managed connection factory returned actualyl just wraps whichever JMS vendor connection factory that is being used and cahces it.

[timfox]

arjan tijms wrote:

I'm not on HornetQ yet, but on the previous version (JBM) I tried the equivalent of new HornetQQueue():

Why don't you just use session.createQueue() on the standard JMS API to give you a reference to the queue? This is standard JMS so will be portable (unlike the code above).

And, before anyone says it, session.createQueue() DOES NOT create an actual queue on the *server*, it simply returns a client side reference to a queue that *already exists* on the server. (See JMS Javadoc for more info)

[timfox]

Andy Taylor wrote:

My entire goal here was to have good performance for messaging and this seems to do the trick nicely. I'm still a bit in the dark how the connection pooling of the bisocket connector actually influences or interacts with the highler level JMS connection pooling in JBM, but as Tim mentioned this is an issue with the previous version of HornetQ (JBM). The current version uses Netty and a quick glance at it seems to reveal it doesn't uses a connection pool of its own.

Using the JmsXA connection factory will still use HornetQ factories under the cover. The managed connection factory returned actualyl just wraps whichever JMS vendor connection factory that is being used and cahces it.

+1.

There's a wiki page on the HornetQ wiki which explains in detail how JCA connection pooling works with JMS providers

[timfox]

arjan tijms wrote:

My entire goal here was to have good performance for messaging and this seems to do the trick nicely. I'm still a bit in the dark how the connection pooling of the bisocket connector actually influences or interacts with the highler level JMS connection pooling in JBM,

Neither JBoss Messaging nor HornetQ do any connection pooling.

Connection pooling is done by the JCA implementation, which is a part of JBoss application server. This is completely different code and a different team to either of the messaging teams.

The wiki page I pasted in my last post should clear up the confusion for you.

[atijms]

Tim Fox wrote:

Why don't you just use session.createQueue() on the standard JMS API to give you a reference to the queue? This is standard JMS so will be portable (unlike the code above).

Okay, that sounds even better

I noticed you mentioned this earlier:

Now, I do know that you can just create destination references on the  fly on the client side using HornetQ. By simply using  HornetQJMSClient.createXX(), or you can just use  session.createQueue()/createTopic() which is part of the standard JMS  API. But I don't know if that's the proper/legal *JEE* way of doing  things.

Just out of curiousity, I do wonder why you say you don't know if that's the legal Java EE way, since all the code that implements this stuff does have your name at the top, e.g. implementation classes in JBM like ClientSessionDelegate etc. I would guess you were the expert here and knew exactly whether that was the proper way or not.

And, before anyone says it, session.createQueue() DOES NOT create an actual queue on the *server*, it simply returns a client side reference to a queue that *already exists* on the server. (See JMS Javadoc for more info)

It seems to be very clear The comment in the SessionEndPoint interface for createQueue states:

/**
    * Creates a queue identity given a Queue name. Does NOT create the physical queue. The physical
    * creation of queues is an administrative task and is not to be initiated by the JMS API, with
    * the exception of temporary queues.
    */
   JBossQueue createQueue(String queueName) throws JMSException;

Thanks for the help.

[timfox]

arjan tijms wrote:

Just out of curiousity, I do wonder why you say you don't know if that's the legal Java EE way, since all the code that implements this stuff does have your name at the top, e.g. implementation classes in JBM like ClientSessionDelegate etc. I would guess you were the expert here and knew exactly whether that was the proper way or not.

JEE is the domain of the app server guys, not us.

Yes, we probably know more about JEE than most people, but we are not the domain experts.

There are lots of examples of stuff that is perfectly legal when using raw JMS, but is illegal when using JMS in a JEE environment, e.g. from inside an EJB.

E.g. you can't set an exception listener or create a consumer using a connection obtained from inside an EJB.

[atijms]

Tim Fox wrote:

Why don't you just use session.createQueue() on the standard JMS API to give you a reference to the queue? This is standard JMS so will be portable (unlike the code above).

And, before anyone says it, session.createQueue() DOES NOT create an actual queue on the *server*, it simply returns a client side reference to a queue that *already exists* on the server. (See JMS Javadoc for more info)

I tested this now and found out they are not exactly the same really. The session.createQueue() appears to be a little more heavy-weight. As a test I used a queue name that doesn't exist:

Destination direct = new JBossQueue("bla"); // works
Destination test = session.createQueue("bla"); // throws

The second one throws an exception, and judging from the stacktrace it seems to have done quite a bit of work:

17:20:11,360 ERROR [STDERR] javax.jms.JMSException: There is no administratively defined queue with name:bla
17:20:11,360 ERROR [STDERR]     at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createQueue(ServerSessionEndpoint.java:299)
17:20:11,361 ERROR [STDERR]     at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$createQueue$aop(SessionAdvised.java:105)
17:20:11,361 ERROR [STDERR]     at org.jboss.jms.server.endpoint.advised.SessionAdvised$createQueue_6431069199924553036.invokeTarget(SessionAdvised$createQueue_6431069199924553036.java)
17:20:11,362 ERROR [STDERR]     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
17:20:11,362 ERROR [STDERR]     at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
17:20:11,362 ERROR [STDERR]     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
17:20:11,363 ERROR [STDERR]     at org.jboss.jms.server.endpoint.advised.SessionAdvised.createQueue(SessionAdvised.java)
17:20:11,363 ERROR [STDERR]     at org.jboss.jms.wireformat.SessionCreateQueueRequest.serverInvoke(SessionCreateQueueRequest.java:74)
17:20:11,363 ERROR [STDERR]     at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
17:20:11,364 ERROR [STDERR]     at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
17:20:11,364 ERROR [STDERR]     at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
17:20:11,365 ERROR [STDERR]     at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
17:20:11,365 ERROR [STDERR]     at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
17:20:11,366 ERROR [STDERR]     at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
17:20:11,366 ERROR [STDERR]     at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
17:20:11,367 ERROR [STDERR]     at org.jboss.remoting.Client.invoke(Client.java:1724)
17:20:11,367 ERROR [STDERR]     at org.jboss.remoting.Client.invoke(Client.java:629)
17:20:11,367 ERROR [STDERR]     at org.jboss.remoting.Client.invoke(Client.java:617)
17:20:11,368 ERROR [STDERR]     at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
17:20:11,368 ERROR [STDERR]     at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
17:20:11,369 ERROR [STDERR]     at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$createQueue$aop(ClientSessionDelegate.java:319)
17:20:11,369 ERROR [STDERR]     at org.jboss.jms.client.delegate.ClientSessionDelegate$createQueue_6431069199924553036.invokeTarget(ClientSessionDelegate$createQueue_6431069199924553036.java)
17:20:11,369 ERROR [STDERR]     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
17:20:11,370 ERROR [STDERR]     at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
17:20:11,370 ERROR [STDERR]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
17:20:11,370 ERROR [STDERR]     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
17:20:11,371 ERROR [STDERR]     at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
17:20:11,371 ERROR [STDERR]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
17:20:11,372 ERROR [STDERR]     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
17:20:11,372 ERROR [STDERR]     at org.jboss.jms.client.delegate.ClientSessionDelegate.createQueue(ClientSessionDelegate.java)
17:20:11,372 ERROR [STDERR]     at org.jboss.jms.client.JBossSession.createQueue(JBossSession.java:250)

Where the new JBossQueue() just directly instantiates a tiny wrapper class (it contains only a String and a boolean), the session.createQueue seems to do a lot of work, including checking whether the queue exists. If I already happen to know the exact queue name, I don't really want these checks to be done each and every time (otherwise I can just request the Destination out of JNDI anyway).

(p.s. this was executed from the Servlet container, not from an EJB)