Issues with MDB request/replies in 3.0.0beta?
geraldthewes Apr 19, 2002 4:05 PMI was trying to send replies from messages sent
to an MDB to a temporary queue
created in the producer client (an MDB itself).
But this does not appear to work for me.
On the producer side, waiting for the reply
always timed out (10,000 ms wait, - the consummer
MDB is done with it's work and sends it's reply
back in about 3s according to log information).
The log filed showed that the reply was correctly
sent back (no errors) but the receiver does not seem
to see it.
As far as I can tell, I have coded the consummer
MDB following the common examples out there on
the net.
The receive code use on the producer side looks like:
replyQueue = qSes.createTemporaryQueue();
sender = qSes.createSender(queue);
// Now send it off
String xmlStr = message.toXmlString();
TextMessage msg = qSes.createTextMessage(xmlStr);
msg.setJMSReplyTo(replyQueue);
sender.send(msg);
// Now wait for response
replyReceiver = qSes.createReceiver(replyQueue);
javax.jms.Message replyMsg =
replyReceiver.receive(replyTimeout);
if (null == replyMsg) {
sLog.error("Did not receive a reply for " + message);
} else {
...
}
Nothing obvious appears in the log files.
I have since replaced the temporary queue, with
a permanent queue and have a third MDB wait on the
responses (not a bad change since now I don't
need to wait for the reply) and it all works
fine. The code on the consummer MDB has not
changed (since it sends the reply to
replyQueue = (Queue)aMsg.getJMSReplyTo() )
My reply queue is now set using
replyQueue = (Queue)ctx.lookup("queue/messagestatus");
On the producer side.
Anybody else run into similar problems?
Gievn I'm probably going to stick wih the
permanent reply queue I'm probably not going to
spend a lot more time on solving the
reply/request to a temporary queue problem.
Anyway I'm not sure if I ran into a bug, or simply
did something wrong. Maybe worth saying that
my consummer MDB creates a new JMS session
for each reply (in a method called from
onMesage() so that I close the session as soon
as I'm done with the sending). This is different
from the many samples I have seen out there that
create/destroy the session in ejbCreate()/ejbRemove()
and hold onto it.
Things I was concerned about is a missunderstanding
of the transaction semantics on my part (somehow the reply was
rolled back so although it appeared to be correctly
sent it was never 'delivered').
Or the fact that I close
the session immediately after sending the reply and the temporary queue is
not persistent (but the temporary queue lifetime
should be controlled by the original producer,
not by the session used to send the reply).