| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| message priority |
« View previous topic :: View next topic » |
| Author |
Message
|
| bduncan |
 Posted: Tue Jul 24, 2001 1:30 pm Post subject: |
 |
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Here's a general question, but I can't seem to track it down in the manuals. Does setting message priorities affect how they are dispatched across the network? I was under the impression that message priorities only affect the order in which you get messages from a queue once they have reached their destination. But someone just explained to me that they are sending a large number of huge messages in a bundle, and during this time they would like to send smaller more important messages. They were under the impression that by setting higher priorities for the smaller messages they would be picked up off the XMITQ and sent across the channel first even though other messages were already waiting. I told them I didn't think this was the case, and that the only way they could achieve what they wanted is by defining parallel channels and separate XMITQs between the queue managers for the larger lower priority messages and the higher priority smaller messages. Do I have this picture right?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
 |
| bduncan |
| Posted: Tue Jul 24, 2001 2:13 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Hmm, well I think I figured this one out too after pouring over the manuals. It appears that you can use message priority to affect the order in which the messages are sent across a channel if you change the MsgDeliverySequence on the transmit queue from FIFO to PRIORITY. This way, when a higher priority message gets put to the XMITQ, it will be placed closer to the top of the queue, ahead of any lower priority messages. Furthermore, messages of the same priority will still be FIFO on the XMITQ which is a necessary thing in the case of our particular application. It appears that MsgDeliverySequence defaults to Priority on our Unix queue managers: SYSTEM.DEFAULT.LOCAL.QUEUE is set up this way, whereas on our MVS systems they appear to default to FIFO.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Jul 24, 2001 3:26 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
MQSeries does not guarantee the order of delivery of messages even of equal priority on a transmit queue. There are scenarios where you could put messages
A->B->C and have them arrive on the queue as A->C->B etc ... admitedly they are rare but possible. If order of messages is required, consider logical message ordering .... |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 25, 2001 11:20 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well I know that the way MQSeries batches messages for transmission across TCP/IP can throw messages out of order, but I was under the impression that they would be placed back in FIFO order on the destination queue. In other words, if I put A->B->C to a remote queue definition, they might get dispatched across the network as B->A->C, but if I look at the destination queue it would be A->B->C again. Is this just wishful thinking? We have a very old application that doesn't use logical groups because it was designed when our MVS system had an old version of MQ that didn't support grouping, and it just sort of expects messages to be in the order it sends them. In other words, it's taking a very large text file, breaking it up into a bunch of messages all with the same CorrelId, and sending them to another queue manager. On the other end, the receiving application simple matches against the CorrelId and pulls off in FIFO order until there are no messages left on the queue with that CorrelId (I know this is not a good method for many reasons, but this code is 5 years old, and I didn't write it! hehe) If what you are saying is true that we can't depend on A->B->C staying as A->B->C on the destination queue then we probably need to think about a program redesign. Of course, it amazes me that nobody has noticed any corrupted files because you would think that every now and then they would get out of order... hmm...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jul 31, 2001 12:40 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Neil,
I have been speaking to some people who believe that MQSeries guarantees FIFO delivery of messages. That is, if you put A->B->C, you get A->B->C on the other end. This seemed to go against what you were saying, so I decided to try and track it down. This is what I discovered in the Intercommunications book:
The channel uses sequence numbers to assure that messages are delivered,
delivered without duplication, and stored in the same order as they were taken
from the transmission queue. The sequence number is generated at the sending
end of the channel and is incremented by one before being used, which means that
the current sequence number is the number of the last message sent.
And then:
If an application puts a sequence of messages to the same destination queue, those
messages can be retrieved in sequence by a single application with a sequence of
MQGET operations, if the following conditions are met:
* All of the put requests were done from the same application.
* All of the put requests were either from the same unit of work, or all the put
requests were made outside of a unit of work.
* The messages all have the same priority.
* The messages all have the same persistence.
* For remote queuing, the configuration is such that there can only be one path
from the application making the put request, through its queue manager,
through intercommunication, to the destination queue manager and the target
queue.
* The messages are not put to a dead-letter queue (for example, if a queue is
temporarily full).
* The application getting the message does not deliberately change the order of
retrieval, for example by specifying a particular MsgId or CorrelId or by using
message priorities.
* Only one application is doing get operations to retrieve the messages from the
destination queue. If this is not the case, these applications must be designed to
get all the messages in each sequence put by a sending application.
Note: Messages from other tasks and units of work may be interspersed with the
sequence, even where the sequence was put from within a single unit of
work.
If these conditions cannot be met, and the order of messages on the target queue is
important, then the application can be coded to use its own message sequence
number as part of the message to assure the order of the messages.
So it seems that IBM is saying that if you can meet these conditions, you can be confident that you'll receive messages in the order that you sent them...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Jul 31, 2001 1:05 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| Yup. But that is quite a long list of assumptions at the bottom. Especially dead-letter queue processing and others. If you can be sure that you maintain all those invariants, you can indeed have confidence that you will get the messages out in the order in which they were put. |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jul 31, 2001 3:10 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well, I don't have much confidence in that. And I don't like leaving things to chance. Unfortunately the technical issues aren't always the factors that ultimately drive the decision whether to upgrade an application or not. So it looks like I'll just have to keep my fingers crossed... 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| dickchirko |
| Posted: Sat Sep 29, 2001 11:42 am Post subject: |
|
|
Newbie
Joined: 28 Sep 2001
Posts: 1
|
| Quote: |
On 2001-07-24 16:26, kolban wrote:
MQSeries does not guarantee the order of delivery of messages even of equal priority on a transmit queue. There are scenarios where you could put messages
A->B->C and have them arrive on the queue as A->C->B etc ... admitedly they are rare but possible. If order of messages is required, consider logical message ordering ....
|
can you tell me where this is documented. I have exactly this problem. Very occasional reception of messages out of order. Whenever this happens the MQ log shows identical time stamps. Thanks, dick |
|
| Back to top |
|
|
| kolban |
| Posted: Sat Sep 29, 2001 4:03 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
The following reference from the Intercommunication Guide identifies a pretty good list of when message might not be delivered in sequence. Do all these conditions apply in your instance?
[ This Message was edited by: kolban on 2001-09-29 17:04 ] |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
