| Author |
Message
|
| flaccy |
 Posted: Wed Aug 22, 2012 5:54 am Post subject: Message consuming in order that has been received by the q |
 |
|
Newbie
Joined: 15 Sep 2010
Posts: 3
|
I have got a MDB (Glassfish 3.1.2, Java EE 6) which listens to WebSphere MQ (v7.0.1.8 ). It does not picks up the messages in the order that has been received by the Queue. How can i make it read it in that order?
So when I put messages in order 1,2,3,4,5 MDB reads 1,3,4,5,2..etc
I use IBM Websphere MQ resourse adapter. (wmq.jmsra)
Thanks for yours reply!
Flaccy |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 22, 2012 6:00 am Post subject: Re: Message consuming in order that has been received by the |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| flaccy wrote: |
| I have got a MDB (Glassfish 3.1.2, Java EE 6) which listens to WebSphere MQ (v7.0.1.8 ). It does not picks up the messages in the order that has been received by the Queue. How can i make it read it in that order? |
Use the WMQ facilities built into the software to sequence the messages.
Note that reading messages in sequence is called "message affinity". You'll find many discussions in here on why that's not a good idea, most of which also discuss how to achieve what you're asking.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 22, 2012 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So if you stop your MDB, and you put the messages on the queue 1,2,3,4,5,6 and then you start your MDB, then it does not read them in that order?
You should not rely on the order of messages being put on the queue. It's bad.
If you need to process a set of messages in a certain order, you need to make sure that the messages have that order identified on them in message itself or in the message metadata. For example by using a group of messages.
If the messages are being put by more than one application, you can not guarantee that the first message put will be available before the second, because you can not guarantee that the first app will commit before the second. |
|
| Back to top |
|
|
| flaccy |
| Posted: Wed Aug 22, 2012 6:17 am Post subject: |
|
|
Newbie
Joined: 15 Sep 2010
Posts: 3
|
| mqjeff wrote: |
| So if you stop your MDB, and you put the messages on the queue 1,2,3,4,5,6 and then you start your MDB, then it does not read them in that order? |
No, it does not read them in that order. The messages are being put by one application.
I would like read them in the order that has been put by the application. (FIFO) |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 22, 2012 6:43 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Change the queue input mode from shared to exclusive. |
|
| Back to top |
|
|
| flaccy |
| Posted: Wed Aug 22, 2012 7:03 am Post subject: |
|
|
Newbie
Joined: 15 Sep 2010
Posts: 3
|
| zpat wrote: |
| Change the queue input mode from shared to exclusive. |
If I change the queue "Default input open option" to exclusive I get an error on the server.log : Mq reason code '2042' (MQRC_OBJECT_IN_USE) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 22, 2012 7:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| flaccy wrote: |
| mqjeff wrote: |
| So if you stop your MDB, and you put the messages on the queue 1,2,3,4,5,6 and then you start your MDB, then it does not read them in that order? |
No, it does not read them in that order. |
How do you know?
Do you see log entries from different threads running instances of the MDB that then have different time stamps?
So it's possible that the messages are *read* from the queue in the correct order, but not *processed* by the MDB thread in that order, or that the messages are *processed* in the correct order, but the log is not *written* in that order.
You CAN NOT DO THIS WITH MORE THAN ONE THREAD.
YOU SHOULD NOT RELY ON QUEUE ORDER. IT'S BAD. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 22, 2012 7:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
You CAN NOT DO THIS WITH MORE THAN ONE THREAD.
YOU SHOULD NOT RELY ON QUEUE ORDER. IT'S BAD. |
Unless both you and the sender have taken very specific action within WMQ to ensure this.
This action does not make it any less of a bad design idea.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 22, 2012 10:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We've had this debate before. It's not bad to rely on a documented feature of MQ.
If there is one producer of messages (of the same priority) and one consumer, they will arrive in order assuming there is only one network path they could take.
One way to ensure there is only one consumer is to change the queue open default to exclusive. You can't do this while the queue is open. Stop the application first. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 22, 2012 10:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| We've had this debate before. It's not bad to rely on a documented feature of MQ. |
Yep. We've had this debate before. I agree that it's not bad to rely on a documented feature of MQ.
But this particular documented feature of MQ relies on a number of factors and a reliability of change control that are outside the control of MQ and in general unreliable in my experience.
And this poster has already shown that they are missing the point about 'one consumer', by using an MDB that has multiple independent threads and then assuming that those threads will process messages read off the queue in order.
| zpat wrote: |
If there is one producer of messages (of the same priority) and one consumer, they will arrive in order assuming there is only one network path they could take.
One way to ensure there is only one consumer is to change the queue open default to exclusive. You can't do this while the queue is open. Stop the application first. |
Right, but again in an MDB situation, the JMS listener will very likely open the queue more than once, which means that setting the queue to a default open exclusive will generate a number of failures after the first open succeeds.
Which, again, appears to match the symptoms described by the original poster. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 22, 2012 11:14 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We do this on a couple of WAS servers, the first one to open the queue gets it. If one server fails the other one can have it.
Don't see the problem really. No point having more than one listener on a single server of course, make the connection pool size 1. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 22, 2012 11:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
We do this on a couple of WAS servers, the first one to open the queue gets it. If one server fails the other one can have it.
Don't see the problem really. No point having more than one listener on a single server of course, make the connection pool size 1. |
It requires planning, and clear documentation and a solid understanding of the solution and governance. And it requires constant vigilance to ensure that unrelated applications don't cause the the conditions ensuring the success of the solution to be altered.
I agree that you've made it work, and that that's a good thing and that there's nothing inherently wrong with the solution you've got.
It's just beyond the capabilities of a lot of shops to manage long term. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 22, 2012 12:04 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Really don't see where you are coming from. There is nothing to manage.
Whereas designing sequence control into the application is quite involved. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 22, 2012 12:20 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Really don't see where you are coming from. There is nothing to manage.
Whereas designing sequence control into the application is quite involved. |
So I set up an application like this, and it's one of two or three applications that are currently using MQ. And it works great.
A year later, the use of MQ has been 'proven out' locally, and five other applications clamor to come on board. And we also need to move to new hardware.
Three of the new applications require MQ clustering and are significantly higher visibility than the existing apps, so the new platform is designed to have all of the qms participate in the MQ cluster.
Six months after migrating to the new platform it is discovered that a random number of messages that should have been processed in order were processed out of order. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 22, 2012 12:39 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You're making things more complex than needs be. This is not a cluster queue. It is a standard queue with exclusive open. End of story.
Most new MQ users can barely code simple puts and get and you want them to manage their own sequencing. Hmm - that'll happen!
MQ cluster queues are over-rated. Never used them, probably never will. If you want to scale up - add more client application servers. |
|
| Back to top |
|
|
|
|
