-
1. Re: Guaranteed Message Sequence
clebert.suconic Jun 9, 2010 11:42 AM (in response to ohughes)I don't understand the question...
A Consumer will receive a message after another.. sequentially.
So, it's up to you how you take the messages out. You take one at the time.
-
2. Re: Guaranteed Message Sequence
ohughes Jun 9, 2010 4:40 PM (in response to clebert.suconic)Ah, ok, so maybe I am confused also, I thought that a consumer would be multi-threaded and be able to handle multiple messages at the same time.
If this is not the case, then my bad!
But if a consumer can handle multiple-messages at a given time then the question still stands, because the consumer could be processing one message in one thread, and the next one in another, which would cause out of synch processing. So the next message should not come off the queue until the previous one has been completed
-
3. Re: Guaranteed Message Sequence
clebert.suconic Jun 9, 2010 5:02 PM (in response to ohughes)1 of 1 people found this helpfulA Consumer will call the message listener, one after another.
If you have MDBs however, you will have multiple listeners. i.e. Multiple Consumers for a Single MDB.
so, you could have multiple parallel requests on a MDB, but on that case you just have multiple consumers. On the case of a group-ID, all the requests will be handled by a single consumer.
If you see anything different, it would be a bug.
But I don't think it will be the case.
-
4. Re: Guaranteed Message Sequence
clebert.suconic Jun 9, 2010 5:04 PM (in response to ohughes)But if a consumer can handle multiple-messages at a given time then the question still stands, because the consumer could be processing one message in one thread, and the next one in another, which would cause out of synch processing. So the next message should not come off the queue until the previous one has been completed
We have no control over that. We don't know when you finished/started your processing.
It's up to you how you make the calls to the consumer, or how you implement the listener method.
If you start a new thread from your consume method and ask HornetQ to send you a new message.. you are telling HornetQ that you are ready for another message. And that's how it should be.
-
5. Re: Guaranteed Message Sequence
ohughes Jun 15, 2010 5:40 AM (in response to clebert.suconic)Perfect, this is what I was worried about, but even if in the MDB situation, it is guaranteed to go to the exact same thread, then the ordering of the message's is guaranteed, thanks.
-
6. Re: Guaranteed Message Sequence
clebert.suconic Jun 16, 2010 9:43 AM (in response to ohughes)Even if you have multiple instances on the MDB (minSession=X), the ResourceAdapter will have one session/internalConsumer for each instance. If you use message-grouping, all the messages will be sent to the same consumer what will guarantee ordering.
The thread may be different (as there's a thread pool) but the consumer will be the same. I.e ordering will be guaranteed.