ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQ Message Delivery Sequence Question

Post new topic  Reply to topic
 MQ Message Delivery Sequence Question « View previous topic :: View next topic » 
Author Message
vignesh2015
PostPosted: Mon Dec 21, 2015 9:58 am    Post subject: MQ Message Delivery Sequence Question Reply with quote

Newbie

Joined: 21 Dec 2015
Posts: 2

Hello All,



We have an local queue on Unix queue manager running in MQ V7.1
That local queue has "Default Sequence" Priority
The application team is asking "How can they change there application configuration to make the messages process through FIFO without changing the Physical Queue Attribute"

Can someone help me in this query.

Thanks
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Mon Dec 21, 2015 10:50 am    Post subject: Re: MQ Message Delivery Sequence Question Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

vignesh2015 wrote:
The application team is asking "How can they change there application configuration to make the messages process through FIFO without changing the Physical Queue Attribute"


Send all their messages with the same priority.

Note that this simply increases the chances of messages arriving in the same sequence as they were put, it doesn't absolutely guarantee it.

Needing messages to arrive on a queue in a given sequence is commonly because of "message affinity", where the processing of the second message in the queue is dependent on the first message in the queue, and the processing of the third messages on the second, and so on with the nth message relying on the n-1th message being processed.

This is a very bad design pattern for a number of reasons. Confirm with your application team they're not doing that.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
vignesh2015
PostPosted: Mon Dec 21, 2015 10:57 pm    Post subject: Reply with quote

Newbie

Joined: 21 Dec 2015
Posts: 2

Thanks

So, do you say that it's always better to change the queue attribute rather asking the sender to send the messages with equal priority?

Please advise

Thanks
Back to top
View user's profile Send private message Send e-mail
fjb_saper
PostPosted: Tue Dec 22, 2015 12:03 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

No what he is saying is laid out in the documentation:
Quote:
You cannot guarantee the order of the messages in a queue if there are multiple paths to deliver the messages to the queue

Think as well of problems that may send some messages to the DLQ and disrupt queue order (queue full) etc...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Tue Dec 22, 2015 5:25 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

vignesh2015 wrote:
So, do you say that it's always better to change the queue attribute rather asking the sender to send the messages with equal priority?


No, what I'm saying is that any application that is trying to ensure messages are processed in the exact order that they're sent is using a very poor design.

My worthy associate has provided a useful quote, and a couple of instances when this design will fall flat on it's face. I'll also point out that it's almost impossible to scale such a design.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Dec 22, 2015 7:24 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You can process messages in order without needing them to arrive on a queue in order.

This requires that your application is actually written to meet the business requirement.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Dec 22, 2015 9:58 am    Post subject: Re: MQ Message Delivery Sequence Question Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

vignesh2015 wrote:
Hello All,



We have an local queue on Unix queue manager running in MQ V7.1
That local queue has "Default Sequence" Priority
The application team is asking "How can they change there application configuration to make the messages process through FIFO without changing the Physical Queue Attribute"

Can someone help me in this query.

Thanks

Message Delivery Sequence only dictates how messages are delivered out of a queue to a consuming application - FIFO (first-in, first-out) or by Priority.

Is the intent of your post that some messages will be delivered to a consuming application FIFO and other messages will be delivered by Priority - out of the same queue? By (to) the same or different consuming apps?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MQ Message Delivery Sequence Question
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.