| Author |
Message
|
| jamesmq |
 Posted: Mon Feb 25, 2008 3:46 am Post subject: Message Priority Editing |
 |
|
Newbie
Joined: 25 Feb 2008
Posts: 3
|
Hi,
I have been searching the online docs for an answer but can't seem to find anyway of editing the priority on a message.
My idea is to decrease the priority of a message if it's backout count is greater than a certain amount. Obviously I would have to do this in my code when the message is picked up which I don't mind doing but would I have to do a mqget followed by a mqput to do this?
Also, adjusting priorities like this, if I applied a MQMD filter combined with MQGET MatchOptions would I have to reopen the queue to get the messages reordered?
Thanks,
James |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 25, 2008 4:09 am Post subject: Re: Message Priority Editing |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jamesmq wrote: |
| My idea is to decrease the priority of a message if it's backout count is greater than a certain amount. Obviously I would have to do this in my code when the message is picked up which I don't mind doing but would I have to do a mqget followed by a mqput to do this? |
Yes. Though clearly if the backout count goes past a certain (application specific) point, you should just give up and put it on the backout queue because it's never going to work.
| jamesmq wrote: |
Also, adjusting priorities like this, if I applied a MQMD filter combined with MQGET MatchOptions would I have to reopen the queue to get the messages reordered?
|
I don't believe so. The queue manager will give you the next message off the queue which matches the criteria specified. The actual order of the messages on the queue is irrelevent (they're stored internally in order of arrival) as the queue manager searches for a match each time a get is issued first message to end (like a database table scan).
(Before anybody says that's not strictly true on z/OS, I know, I'm being simplistic)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jamesmq |
| Posted: Mon Feb 25, 2008 5:49 am Post subject: Re: Message Priority Editing |
|
|
Newbie
Joined: 25 Feb 2008
Posts: 3
|
| Vitor wrote: |
| jamesmq wrote: |
| My idea is to decrease the priority of a message if it's backout count is greater than a certain amount. Obviously I would have to do this in my code when the message is picked up which I don't mind doing but would I have to do a mqget followed by a mqput to do this? |
Yes. Though clearly if the backout count goes past a certain (application specific) point, you should just give up and put it on the backout queue because it's never going to work.
|
A fair point - but due to some data mapping issues, an email will be dispatched to support staff to correct the issue which maybe done very quickly - after which the message can be processed successfully.
With regard to the backout queue alternative, could a 'message ID' be sent in this "error" email so once the manual intervention is complete, the staff can forward that particular message to the "main" queue once again?
I guess you can retieve messages by 'Message ID' ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 25, 2008 6:03 am Post subject: Re: Message Priority Editing |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jamesmq wrote: |
| A fair point - but due to some data mapping issues, an email will be dispatched to support staff to correct the issue which maybe done very quickly - after which the message can be processed successfully. |
Unless the error isn't the data mapping error you're expecting, but some other class of unexpected error or software failure.
| jamesmq wrote: |
With regard to the backout queue alternative, could a 'message ID' be sent in this "error" email so once the manual intervention is complete, the staff can forward that particular message to the "main" queue once again?
I guess you can retieve messages by 'Message ID' ? |
Yes you can and yes you could but why would you? If you've fixed "the error" then the better course of action is to take the entire contents of the backout queue (which logically must be there because of "the error") and dump the lot back into the original queue for another crack at processing.
If you've got any message volume at all, with your method your support people are going to be knee-deep in emails containing message ids in a very short period of time. This is likely to be unmanageable and unpopular.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Mon Feb 25, 2008 7:32 am; edited 1 time in total |
|
| Back to top |
|
|
| jamesmq |
| Posted: Mon Feb 25, 2008 7:17 am Post subject: |
|
|
Newbie
Joined: 25 Feb 2008
Posts: 3
|
Well I'd say 99% of the messages are processed straight away without any manual intervention. Some currently fail due to database blocking (hopefully most of which would be avoided if we retried say, 3 times ie BOThreshold = 3) and some fail due to data mapping issues.
Each message is independant of one another so in these cases it would be suitable to reload on a message by message basis, with the capability to reload the entire error queue should a technical issue be the cause of failure.
Thanks for your very well written help Vitor. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 25, 2008 7:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jamesmq wrote: |
| Some currently fail due to database blocking (hopefully most of which would be avoided if we retried say, 3 times ie BOThreshold = 3) |
Quite so.
| jamesmq wrote: |
| and some fail due to data mapping issues. |
My point is that it's feasible that the mapping issues could be caused by a mis-judged application change, causing large numbers of errors quickly. Obviously you're in the best position to judge the likelyhood of this happening on your site.
| jamesmq wrote: |
| Each message is independant of one another so in these cases it would be suitable to reload on a message by message basis, with the capability to reload the entire error queue should a technical issue be the cause of failure. |
Don't forget that there are support packs capable of moving messages from one queue to another. No point reinventing the wheel.
| jamesmq wrote: |
| Thanks for your very well written help Vitor. |
You're quite welcome. Thanks for your well-written enquiry. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 25, 2008 7:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The upside to using a backout queue rather than a lower priority is that you have absolute control over when the message gets reprocessed.
If you requeue failed messages to the input queue, with a lower priority, then you may reprocess it a) immediately, b) never, and it's entirely dependent on the volume of incoming messages with a higher priority.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 25, 2008 7:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Message priority is a frequent cause of so-called "lost messages". Lower priority messages, as Jeff suggests, may never be processed - if higher priority messages continue to arrive on the queue.
_________________
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 |
|
|
|
|
