Is it possible to keep a message in a queue until it is consumed by an MDB?

[swapnonil.mukherjee]

Hi Everybody,

I am using HornetQ 2.0 GA with JBoss 5.1GA. I am sending messages from a Stateless Session Bean and consuming them using a Message Driven Bean. I have set up a master/slave topology where the both the master and slave share the same storage for all queues.

What I want to do is to keep a message in a queue until the MDB which has been allotted this message says that it has completely finished processing it.

The sequene should be like this

In normal course of operation

1. Client sends a message to a queue
   
2. HornetQ picks up the message from the qeue and delivers it to a new instance of an MDB, but the message is not taken off the queue.
   
3. The MDB finishes processing of the message.
   
4. The message is finally taken off the queue.
   

In case the MDB encounters an exception, or the server running executing the MDB shuts down.

1. Client sends a message to a queue
   
2. HornetQ picks up the message from the qeue and delivers it to a new instance of an MDB, but the message is not taken off the queue.
   
3. Master shuts down
   
4. The message is not taken off the queue and it remains there, as the MDB instance at the Master which had consumed this message server could not finsih it's job.
   
5. HornetQ picks up the message again and delivers it to the next available MDB on the Slave.
   

So by using a shared queue, and by not taking messages off the queue until they are fully consumed, I think I can achieve full DR.

Therefore my question is: Is it possible to keep a message in a queue until it is consumed by an MDB?

[clebert.suconic]

I'm not really sure what you're asking.

You're describing the regular ACK procedure that we implement.  A message stays in delivering state until it's ACKed. In case of failure the messages "comes back" to the queue, and that's already implemented.

BTW: you should use the latest version. 2.0.0 is sort of old now, and we fixed a few bugs since then.

[swapnonil.mukherjee]

Hi Clebert,

Before I recieve another blast from Tim asking me to read the documentation: Could you please elaborate what you meant by?

You're describing the regular ACK procedure that we implement.  A message stays in delivering state until it's ACKed. In case of failure the messages "comes back" to the queue, and that's already implemented.

Could you please tell me which acknowledgement mode should I use to get this feature?

A small code snippet would be very helpful.

I read through the documentation. But essentially I could not understand whether the JMS acknowledgement modes like AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE supports the use case I have specified.

I also could not understand whether the HornetQ specfic feature of asynchronous acknowledgement as illustrated via 11.1.45 supports this use case.

[swapnonil.mukherjee]

With regards to your request to upgrade from 2.0. We have a plan to upgrade. But we want to upgrade to 2.2, once that is out. I learnt from the HornetQ Dev Forum that a number of new features related to Clustering are planned for release 2.2.

So we would rather wait for 2.2.

[clebert.suconic]

Before I recieve another blast from Tim asking me to read the documentation

You don't need to wait for Tim... I can make the honors! RTFM! ;-)

You're describing a regular ACK process.. how can you ask what I mean on a simple statement like that?

There are only 4 possible ways to implement ACK. You ACK messages individually (Auto_ACK), transactionally (a commit will remove the messages from the queue & memory), DUPS_OK (Batch ACK but that means possibly duplicating a receive)....

that covers all possible combinations... with the caveat that no other consumer can receive a message while one consumer already received it.

I don't think you can reinvent the wheel here. That's how every single Messaging system does it. (I know all of them)

[clebert.suconic]

also, GIYF:

http://www.google.com/search?source=ig&hl=en&rlz=&=&q=jms+tutorial&aq=f&aqi=g10&aql=&oq=&gs_rfai=

http://download.oracle.com/javaee/1.3/jms/tutorial/