-
1. Re: Is it possible to keep a message in a queue until it is consumed by an MDB?
clebert.suconic Aug 31, 2010 10:44 AM (in response to swapnonil.mukherjee)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.
-
2. Re: Is it possible to keep a message in a queue until it is consumed by an MDB?
swapnonil.mukherjee Aug 31, 2010 11:30 AM (in response to clebert.suconic)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.
-
3. Re: Is it possible to keep a message in a queue until it is consumed by an MDB?
swapnonil.mukherjee Aug 31, 2010 11:34 AM (in response to clebert.suconic)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.
-
4. Re: Is it possible to keep a message in a queue until it is consumed by an MDB?
clebert.suconic Aug 31, 2010 11:43 AM (in response to swapnonil.mukherjee)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)