Is async available to JMS Remoting?

This quote got me thinking:

"The JMS remoting support in the Spring Framework is pretty basic - it sends and receives on the same thread and in the same non-transactional Session, and as such throughput will be very implementation dependent. Note that these single-threaded and non-transactional constraints apply only to Spring's JMS remoting support. "

Can I do async communication with Spring JMS Remoting?

A lot of the design I have is expecting to be able to do that. I want to use Spring Remoting to replace the current CORBA RMI with JMS. By using remoting we can keep the clients code the same and just inject the client-side proxies. We are also using Camel/ActiveMQ if any of that matters.

Thanks in advance,


Andrew

If I am correct, I think the wording of that quote is what is confusing. JMS is asynchronous. What the statement is saying is that if you use Spring's JmsTemplate to receive messages from a JMS destination, it is a blocking call on the one thread. Meaning it just sits there on that one thread till a message appears, then passes it to the receiver, then goes right back to blocking and waiting on that thread till another message appears. This thread is not the same thread that sent the message in the first place. When using the JmsTemplate to send a message, it sends it on one thread, but once on the destination, it doesn't wait for a response.

Hope that helps clear things up.

Mark

Well actually that is not what he meant. Spring Remoting can be used to create proxies in such a way that the client receives a proxy to the actually implementation on the server, without even knowing it. That is Spring Remoting and has several implementations, hessian, burlap, http and JMS.

To answer the question no you cannot do async with JMS remoting simply because it isn't intended for that use. If you want something more elaborate I suggest taking a look at Spring Integration (and do something with a gateway and queue channel).

There is a remoting for JMS?

I thought there was only RMI, HttpInvoker, Hessian and Burlap. Why was there one for JMS?

Thanks

Mark

There still IS one... Why not, sometimes you only have JMS available (standalone application) or you already have JMS configured and opened up (getting http up and running in large organizations can be cumbersome). So hence a JMS one.

Ah. I checked out the documentation and saw it. Even saw the quote the op posted. I see there is also remoting with JAX-RPC and JAX-WS.

So for the JMS proxy created, I was curious. Does it generate its own queues on the fly, or do you still have to have them configured in JMS already? Would it need (does it use) 2 queues, one for sending the request and another for the response?

I am going to try it out and see what I get, as well as check out more of the documentation on it.

Personally, I probably would have chosen RMI for a stand-alone application, or one of the others. ;)

Mark

It uses temporary queues (I suggest taking a look at the source code). RMI is harder to do then JMS (also uses different ports which can again be a pain to get opened). It is also nice to just have the choice...

Thanks Marten, I will look at that code.

For the original poster KingAndrew. Listen to what Marten said, not what I said. I had thought your question was in reference to JMS and JMS Template, and I was wrong.

Mark