| Author |
Message
|
| MQEnthu |
 Posted: Thu Jun 18, 2009 8:50 pm Post subject: |
 |
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
So this means the expired messages should be deleted from the queue by scavenger process and not when the MQGet is issued to the queue? If this is the case, from V6.0.2.5 onwards the expired messages should not pile up in the queue (considering queue is not browsed) and should not cause the queue to be full...(as the scavenger process discards the expired message)
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jun 18, 2009 11:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQEnthu wrote: |
| So this means the expired messages should be deleted from the queue by scavenger process and not when the MQGet is issued to the queue? |
No, it means the expired messages should be deleted from the queue by scavenger process or when the MQGet is issued to the queue, as per the documentation segement you posted.
| MQEnthu wrote: |
| If this is the case, from V6.0.2.5 onwards the expired messages should not pile up in the queue (considering queue is not browsed) and should not cause the queue to be full...(as the scavenger process discards the expired message) |
A bit of an assumption there, that the scavenger process will clear out expired messages before the queue fills. The behaviour of this process is not documented so you can't say with certainty "ah, this queue has a depth of 100, holds 80 expired messages and another 20 have just shown up so the scavenger is bound to clear out the 80 and free some space". It might. It might not. 3000 messages might suddenly arrive and fill the queue anyway.
2 things you can be certain of here:
- When you read or browse the queue the expired messages will be deleted
- When you read or browse the queue your application will not receive an expired message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Jun 19, 2009 5:15 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
I liked the way this post has been carried out. It contains a lot of discussion and information inherited by masters (as always) of their field.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Jun 19, 2009 6:14 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Vitor wrote: |
- When you read or browse the queue the expired messages will be deleted |
Does the MQGet first check the expiry interval of a message and then perform the required task or it's qmgr's responsibility to clear a msg as soon as it sense that there is a process which want to read/browse message from a queue?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 19, 2009 6:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Does the MQGet first check the expiry interval of a message... |
Yes, when the message is touched by an MQGET.
| Quote: |
| and then perform the required task |
The application successfully MQGETs the message only if the message has not expired.
| Quote: |
| or it's qmgr's responsibility to clear a msg |
Yes.
| Quote: |
| as soon as it sense that there is a process which want to read/browse message from a queue? |
As from the extensive discussion in this post, the qmgr purges expired messages either at MQGET or when the expired message process can be started (on platforms where such a process exists.
_________________
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.
Last edited by bruce2359 on Fri Jun 19, 2009 6:31 am; edited 1 time in total |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jun 19, 2009 6:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| MQGET, as in the application, will never see an expired message. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 19, 2009 8:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
The Expiry Scavenger on Unix / Windows was as of 6.0.0.0.
As I understand it, it only deals with queues that are "loaded", that is open by someting, even if just for MQINQ. If the q is not open, the q will not be looked at by this process.
This is what I remember, and not 100% sure on it. That does not worry me, because nowhere in the MQ manuals does it say what this is, how it works, or what I can design around it. So I do not rely on it. At all.
All I know is that my app will never get an expired message.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 19, 2009 9:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
One more view of this issue:
Computer architecture describes what an application program 'sees' while executing in an environment. (As an example: z/Series folks are probably familiar with the z/Architecture Principles of Operation. This manual describes the architecture of z/Series hardware image.)
Corinthian columns (to Google you go) describe an architectural view (what you see) of something used in construction. The definition does not tell you exactly how or why or if. Rather it paints a picture - metaphorically.
WMQ applications must be coded to conform to WMQ architecture. WMQ architecture is described by the manuals (Application Programming Reference, Application Programming Guide, WMQ Security, WMQ System Admin, and others). Not conforming will yield a wide variety of errors - often, but not limited to, application abends.
Architecture doesn't tell you exactly how something is accomplished; only that you can (and must) depend on the behavior as defined in the architecture manuals. The exactly explanation will, without doubt, change over time as the hardware platforms become more powerful, RAM and disk get cheaper, authors define new capabilities or learn new ways to improve throughput.
_________________
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 |
|
|
| MQEnthu |
| Posted: Sun Jun 21, 2009 9:56 pm Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
Hi Guys, Thank you very much for all your thoughts on this. 
Since there is no documentation regarding the scavenger process on how it works/when it gets triggered and no one has seen its behaviour (on WINDOWS), I would say it is not a good idea to realy on it.
Thank you once again 
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jun 21, 2009 10:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQEnthu wrote: |
| I would say it is not a good idea to realy on it. |
As an admin, you can rely on it only in so far as you rely on all the other background queue manager processes.
As a user, you can only rely on the fact that you'll never get an expired message in a get call.
So I agree with you; on any platform other than z/OS it's not something you need to give a second thought to because there's nothing you can do with it. This will change only if Windows gets the configuration command currently available on z/OS, when it will become an admin task like setting max message length and queue depth.
And like them, will be left at the default value until something goes wrong!!! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sun Jun 21, 2009 11:26 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Vitor
| Quote: |
2 things you can be certain of here:
- When you read or browse the queue the expired messages will be deleted
- When you read or browse the queue your application will not receive an expired message. |
When we put the message on the queue with a finite expiry value, we can see those message(s) on the queue when its been 'Browsed' in MQ Explorer.
There is a note in that 'Browse' window : "All available messages on the queue have been browsed. Press the refresh button for new messages."
Until we hit 'Refresh' we can see all those messages ( Messages with Expiry and Messages without Expiry ).
That means Either we open a new 'Browse' window by closing the previous one for that queue OR hitting the 'Refresh' in the same 'Browse' window , will do the same thing in the background to present the available message(s) on that queue.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 22, 2009 4:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| MQEnthu wrote: |
Since there is no documentation regarding the scavenger process on how it works/when it gets triggered and no one has seen its behaviour (on WINDOWS), I would say it is not a good idea to realy on it.
|
No one said it doesn't exist on Windows. In fact the error log snippet I posted above came from a Windows QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 22, 2009 5:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I would say it is not a good idea to realy on it. |
Like all other pieces of infrastructure, you have no choice but rely on it for what it accomplishes. You rely on internal queue-manager agent code, even though it is not documented.
Other than lack of documentation on the scavenger, what is your concern? What problem/symptom have you experienced?
_________________
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 |
|
|
| Vitor |
| Posted: Mon Jun 22, 2009 5:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
Until we hit 'Refresh' we can see all those messages ( Messages with Expiry and Messages without Expiry ).
|
Yes.
But what's your point? MQExplorer's a really cumbersome way of monitoring queue depths.
But that's off topic. I think we're all agreed on the situation per pro expired messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 22, 2009 5:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Until we hit 'Refresh' we can see all those messages ( Messages with Expiry and Messages without Expiry ). |
This is stating the obvious.
Any application is run at some point-in-time. It sees what exists at that point-in-time, and displays it on your screen. Immediately after the display, messages might expire, new messages might arrive in a queue, the qmgr might be shut down.
To keep the application view current, you can either keep doing the refresh thing, OR set the auto-refresh value very, very low; but then you would be interrupted continuously with auto-refreshes.
_________________
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 |
|
|
|
|
