Message driven bean not responding until client method is complete

Question

Hi,

I have a MDB deployed on Jboss 4.2.2 and a client on the same server that produces messages and expects a reply from the MDB via a temporary queue created before the message is sent.

When I run the client, I see that it creates the message, puts it in the queue and waits for the reply (no problem so far) ... but when I check in the logs I see that the timeout is reached and no response is received. When the timeout occurs and the client's method is complete the MDB starts processing the message that should have been processed the moment the client put it in the queue. As a consequence of this timing issue, when the MDB tries to reply to the temp queue, it fails since the client is already gone.

If I run the same client from a remote server, I have no problem... The MDB picks up the message from the queue right away and the client receives its response right after the processing is complete.

I'm using container managed transactions. I suspect it has something to do with that... I think the client's "send message/receive reply" might be all be considered a transaction before it commits to put the message in the queue... but I'm not sure if this is correct. If this is the case, why did I not see the same behavior from the remote client? is client managed transaction the default setting and that's what my remote server was using?

Any idea how to fix this?

Thanks in advance! PJ

Answer 1

It sounds like there are two problems here. The first is that the request message is not being committed when sent and is probably in the same unit of work as the receive call. As you noted, the key here will be to determine why the behavior changes when remote. Alternatively, explicitly commit the sent message.

The second problem is that the message eventually does commit once the timeout has been reached. Fixing the first problem will turn this into a latent issue that will appear to have been fixed but come back to bite you later. The behavior can vary depending on whether the transport provider thinks this is an exception or not. Ideally a time-out is considered an exception and the transaction rolled back. Assuming that you are able to deal with the send of the request message, the only transaction subject to timeout is the receive of the reply - which you definitely don't want to result in a commit after a timeout or other exception.

Sorry I don't have a more definitive answer. Save your accept for someone who does but do watch out for those transaction boundaries on the receive.