You don't create the QueueSession or QueueConnection yourself, you specify which queue or topic to listen on in the ejb xml configuration.
Yup, that's what I do. And that part works. But I want my ejb to reply to the client's queue, specified in the request's JMSReplyTo field.
My ejb gets the message, seems to send the reply correctly but my client waits forever.
Why use the JMSReplyTo field? The app server will automatically acknowledge the client when the message is persisted. That's what makes it asynchronous. The client should not have to wait for onMessage to be called. I may not be understanding your problem quite right, but it sounds like you are trying to acknowledge to the client manually?
Hum, interesting way to look at it. No, that's not quite what I'm trying to do.
I have a service as a MDB. One of the things the service does is answer requests for information. I mean, the client sends a message saying it needs info and the server answers. It's not really acknowledgment, it's simulating synch calls with assynch request / reply. Does that make sense? Anyway, there's the javax.jms.QueueRequestor class that was created for that, making an assynch request and blocking until the reply comes in.
So, I want my MDB to get a message, do some processing and answer to the client.
Does that make it clearer?
Thanks for looking into this!
Sounds more like a job for a session bean to me. I can't imagine what the advantage is of using a MDB for this application. Basically if you are talking a 1 to 1 relationship between client and MDB and you are trying to do a synchronous call (Block the client until the message has been handled), it sounds like you are trying to replicate behaviour of a stateless session bean. Again, I may not understand your situation completely.
My usage of an MDB has been to have it handle a queue where I want the client to send messages to the queue, and move on. The processing of these messages is left to jboss, however in my case, I am not waiting for any information back from jboss. If you don't mind me asking, why use an MDB if you are not trying to decouple the client from jboss?
Ah! very true. My bean will, in most cases, be used to simply send messages through, no reply. But there's always that 20% when the client expects a reply (from the 80%/20% rule). Now, since it's basicly the same service but with a couple of requests that get replies, I don't really feel like writing two EJBs, you know?
That's really the reason I'm going all MDB. I also have events I need to propagate to clients. I'd rather make it all the same thing, all MDB, everything through JMS, rather than have bits and pieces behaving differently.
I see what you are saying, but in my opinion, write a session bean. What you are trying to do sounds like a stretch of what an MDB is meant for. I may be mistaken, I'm no expert.
Here is what I suggest. Write the session bean with all of your business logic in it. Then, your clients that expect a reply can call this directly. Otherwise, have them send a message, which in turn calls the session bean when it gets the chance, that way you don't have your client waiting for no reason. This way, you are not duplicating business logic, and you don't have to figure out how to make a client wait for a response other than acknowledgement. (Which I didn't even think was possible) I'm interested in hearing how it turns out.
> Here is what I suggest. Write the session bean with
> all of your business logic in it. Then, your clients
> that expect a reply can call this directly.
> Otherwise, have them send a message, which in turn
> calls the session bean when it gets the chance, that
> way you don't have your client waiting for no
> reason. This way, you are not duplicating business
> logic, and you don't have to figure out how to make
> a client wait for a response other than
This sound as a good designpatter to me, where MDB is used where it should be used.
On the other hand it seems a little anoyning that the reply pattern does not work.
Have you tested it outside of an MDB, i.e writing a normal JMS client message listener. Could you test that, jsut to isolate if it is JBossMQ or the MDB container that is not working properly?
you can use two topics or queue to solve this problem in this case.
: First client send message to topic-1 == your MDB will listen to this topic.
: Implement MessageListner inteface in your client. Set it as MessageListner to topic 2. Use recive() to poll this topic.
: You MDB will process message and post reply to Topic2. As soon as your client recives reply close the connection to topic2.
please check this and post reply in forum.
I have an MDB that listens on one queue and later sends a message out on another queue. It seems to work just fine. Different clients are dealing with each queue, however.
> My ejb gets the message, seems to send the reply correctly but my client waits forever.
How are you verifying that the reply is being sent correctly? Have you tried using another client app that just sits and listens for the reply on all possible client ReplyTo queues? If so, does this client get the message?
Maybe there is a problem with the implementation of javax.jms.QueueRequestor, or it's interaction with JBossMQ.
I'm having the same problem: my client never get the replies from the MDB.
Here's the code the MDB uses to reply:
System.out.println("sending reply to " + inMessage.getJMSReplyTo().toString() + "; corrid = " + inMessage.getJMSMessageID()); TextMessage outMessage = queueSession.createTextMessage(); outMessage.setJMSCorrelationID(inMessage.getJMSMessageID()); outMessage.setStringProperty("status","ok"); QueueSender rplySender = queueSession.createSender((Queue)inMessage.getJMSReplyTo()); rplySender.send(outMessage);
And here is the client code that waits for the reply:
QueueReceiver queueReceiver = queueSession.createReceiver(rplyQueue, "JMSCorrelationID='" + rqst.getJMSMessageID() + "'"); TextMessage rply = (TextMessage)queueReceiver.receive(5000);
No error is reported on the bean's side, nor the client side, except a timeout waiting for the reply.
Did you have any success or hint for solving this?
The problem was that I forgot to call
queueConnection.start() before receiving.
I found the answer in the jboss jms examples.
Maybe it's what you are facing also?
Thanks sbi, that's exactly the answer I've been looking for. It all works now! topicConnection.start() was all it took.