|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
separate chl/xmitq vs msg priorities |
« View previous topic :: View next topic » |
Author |
Message
|
jcv |
Posted: Wed May 02, 2012 11:47 am Post subject: separate chl/xmitq vs msg priorities |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
Hello,
I have found this old topic, probably it's not the only one with somewhat similar subject:
http://www.mqseries.net/phpBB2/viewtopic.php?t=131
If there is a request to make transfer of different types of messages mutually independent, isn't there an exceptional scenario in which lower priority messages may disrupt channel by filling up their destination queue which may be not properly consumed, and a dead letter queue, in which case priority would not help higher priority messages to get through the channel, while their destination queue may be properly consumed?
Does that make message priorities inadequate measure to provide transfer without delay caused by less important/urgent messages, or is there a reason why would you prefere priorities over a separate channel? One reason I can think of is that the responsibility can be delegated to application. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed May 02, 2012 6:08 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Whichever way you want to look at it, your monitoring should prevent you from letting the queue fill up to the max. Take measure, stop the sending app... etc...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu May 03, 2012 2:58 am Post subject: Re: separate chl/xmitq vs msg priorities |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
jcv wrote: |
One reason I can think of is that the responsibility can be delegated to application. |
Im not sure i get your meaning. Neither producing nor consuming application is aware of the existence of the xmitq or channel. _________________ 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 |
|
 |
jcv |
Posted: Fri May 04, 2012 4:38 am Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
Qmgrs that I don't administer and to which I have only sdr rcvr channel connection I can monitor only indirectly. I can rely on our partner monitoring capabilities. Meaning is that one can leave coding of proper priorities to application developers, while separate channel and xmitq must be done by mq administrator. There is an option to rely on applications not to code priority explicitely, and to solve things with default priority. |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri May 04, 2012 5:10 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Priority of a message is relevant only to the consumer of a message, and only if MSG delivery sequence queue attribute is set to deliver by priority.
There is an initial priority value in the MD, and there is a queue attribute that can set the priority of a message if the app specified priority-as-queue-def.
Again, apps have little impact on channels. I'm still unsure what your post is pondering. _________________ 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 |
|
 |
mqjeff |
Posted: Fri May 04, 2012 5:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The MCA is a consumer of messages. |
|
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
|
|
|
|