| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQMD Expiry behavior |
« View previous topic :: View next topic » |
| Author |
Message
|
| vishBroker |
 Posted: Mon Feb 11, 2013 7:59 am Post subject: MQMD Expiry behavior |
 |
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
Hi,
Question - How MQMD.Expiry is working?
Details - We have an application, which publishes message on MQ PUB/SUB.
(Mainframe)The application is setting up Expiry to 60 seconds.
When I browse the message from explorer, I see the value as '600'
I know that value is in 10th of seconds. So we can say, the message will live for 60 seconds.
when I refresh the message, the value is being decreased.
This also is okay, as the field'Expiry' will give remaining time.
But the issue is time is NOT decreasing as expected.
even if I check them message after 30 sec or 60 seconds, I still see the message on the queue with value as something like '573'.
What I mean to say is - the field is not getting updated properly( rather, I am failing to understand, how MQ explorer shows the value). Even if I keep on refreshing the messages(explorer->browse Q->refresh) every seconds, I DO NOT see value getting decreased.
I was expecting the value to get decreased by at least 10 every second. ( as value is 10th of second)
So, not sure, how expiry is WORKING.
If I try to read the message after a minute or so, I still get the message.
So - thinking it is explorer issue does not help.- Message is NOT getting discarded after 60 seconds.
In nutshell ->
1. Even if MQMD.Expiry is set as 60, message is NOT getting expired when tried to read after 1 minute.
2. In MQ Explorer - value of 'expiry' field is NOT getting decreased as expected. ( by 10, evey second) ->
Setup -
I have following setup -
MQ - 7.0.1
OS - Windows ( we are testing on windows. But other env are AIX)
Kindly let me know, what I am missing.
Thanks! |
|
| Back to top |
|
 |
| vishBroker |
| Posted: Mon Feb 11, 2013 8:18 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
The value of 'expiry' in the explorer, is NOT getting decreased even by '1' when I refresh it. ( me taking a break of couple of seconds, before refreshing).
I observed that, the value is getting decreased by '1' after 8 seconds or so. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 11, 2013 8:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Go back to basics.
What does the info center actually say?
What does amqsbcg show?
Also, consider this.
Pretend that the mainframe's clock is running 10 minutes faster than the queue manager holding the message.
What does the info center say will happen in this case? |
|
| Back to top |
|
|
| vishBroker |
| Posted: Mon Feb 11, 2013 9:02 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
Thanks.
I had read this from info center
| Quote: |
The value is decremented to reflect the time that the message spends on the destination queue, and also on any intermediate transmission queues if the put is to a remote queue. It can also be decremented by message channel agents to reflect transmission times, if these are significant. Likewise, an application forwarding this message to another queue might decrement the value if necessary, if it has retained the message for a significant time. However, the expiration time is treated as approximate, and the value need not be decremented to reflect small time intervals |
I understand, that. But I guess, 8 seconds is sufficient time to get reflected.
And, if it gets reflected after 8 seconds, why the value is getting decreased by only '1'.
here is what I get
| Quote: |
MQGET of message number 5
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : 597 Feedback : 0
Encoding : 546 CodedCharSetId : 437
Format : 'MQHRF2 '
Priority : 0 Persistence : 0
MsgId : X'414D51204445564D5150533031202020ED590950276EC25D'
CorrelId : X'414D51204445564D5150533031202020ED590950274C41B6'
BackoutCount : 0
ReplyToQ : '
ReplyToQMgr : 'MQ53
** Identity Context
UserIdentifier : 'MUSR_MQADMIN'
AccountingToken :
X'16010515000000687F086DE72E411AC6B23C48EF0300000000000000000000
ApplIdentityData : ' '
** Origin Context
PutApplType : '26'
PutApplName : 'DEVMQPS01 '
PutDate : '20130211' PutTime : '16392731'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 1204 bytes
00000000: 5246 4820 0200 0000 B400 0000 1103 0000 'RFH ...........
00000010: 2500 0000 4D51 5354 5220 2020 0000 0000 '%...MQSTR ...
00000020: B804 0000 6800 0000 3C75 7372 3E3C 436C '....h...<usr><C
00000030: 6965 6E74 4E61 6D65 3E33 443C 2F43 6C69 'ientName>3D</Cl
No more messages
MQCLOSE
MQDISC
C:\Documents and Settings\vishnu.pandit>time
The current time is: 11:41:45.67
|
And after 9 minute or so
| Quote: |
MQGET of message number 5
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : 580 Feedback : 0
Encoding : 546 CodedCharSetId : 437
Format : 'MQHRF2 '
Priority : 0 Persistence : 0
MsgId : X'414D51204445564D5150533031202020ED590950276EC25D'
CorrelId : X'414D51204445564D5150533031202020ED590950274C41B6'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'MQ53 '
** Identity Context
UserIdentifier : 'MUSR_MQADMIN'
AccountingToken :
X'16010515000000687F086DE72E411AC6B23C48EF03000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '26'
PutApplName : 'DEVMQPS01 '
PutDate : '20130211' PutTime : '16392731'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 1204 bytes
00000000: 5246 4820 0200 0000 B400 0000 1103 0000 'RFH ............'
00000010: 2500 0000 4D51 5354 5220 2020 0000 0000 '%...MQSTR ....'
00000020: B804 0000 6800 0000 3C75 7372 3E3C 436C '....h...<usr><Cl'
00000030: 6965 6E74 4E61 6D65 3E33 443C 2F43 6C69 'ientName>3D</Cli'
00000040: 656E 744E 616D 653E 3C52 6163 6669 643E 'entName><Racfid>'
C:\DOCUME~1\VISHNU~1.PAN>time
The current time is: 11:50:56.03
|
These (time and amqsbcg o/p) are from queue manager host (windows box).
I still see that the time is NOT getting expired as expected(atleast my expectation). |
|
| Back to top |
|
|
| vishBroker |
| Posted: Mon Feb 11, 2013 9:10 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
FYI - this is PUB/SUB env.
I have created a subscriber and putting the message onto the queue.
No appliaction is reading the message from the queue. I do mannual browse and read.
I do not see , message being discarded even after 5 minutes.
cosidering, MQ internal job might run every 300 seconds( haven't changed the property- so runs as default), I am okay with queue depth not decreasing but, when I browse the message after 5 mins, whose expiry is 60 seconds (value as 600), I was expecting it to be deleted(discarded). That is not happening. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Mon Feb 11, 2013 9:16 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
is it has anything to do with puttime? I think NOT, but still would like to know expert opinion.
puttime shows - PutDate : '20130211' PutTime : '16392731'
a GMT time. And I am browsing on EST time. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 11, 2013 9:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
puttime is always in gmt
so is putdate |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 11, 2013 10:17 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| vishBroker wrote: |
I do not see , message being discarded even after 5 minutes. ... I was expecting it to be deleted(discarded). That is not happening. |
First, expired messages will never be delivered to an application.
Second, at present, and on midrange platforms, garbage collecting (deleting expired messages) takes place when next the queue is accessed.
_________________
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 |
|
|
| vishBroker |
| Posted: Mon Feb 11, 2013 10:32 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
[quote: bruce2359];
First, expired messages will never be delivered to an application.
Second, at present, and on midrange platforms, garbage collecting (deleting expired messages) takes place when next the queue is accessed.;[/quote]
yes. that is what I am trying to say - message is NOT discarded, even after expiry duration has elpased.
From the MQMD we see the expiry is '597' and when I browse the message again after 540 seconds(9 min) - I still see the message and the expiry count is 580 - (I have copied it in earlier post)
That tells me, expiry count is getting decreased by 2 after every minute.(not exact calculation but around those values).
So, if I set message expiry as 60 seconds ( value = 600) then it takes almost 300 minutes (1800 sec) to actually expiry message instead of 60 seconds. And that is my question, why so? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 11, 2013 10:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Second, at present, and on midrange platforms, garbage collecting (deleting expired messages) takes place when next the queue is accessed. |
Distributed platforms v7 and later do have an internal job that discards expired messages. It's generally held to run every 300 seconds but is not a configurable property nor have I seen anything in the official IBM documentation that mentions this 300 second limit.
Even on z/OS, where there is a configurable job, there's no absolute guarantee it will run on that schedule, or will collect all the messages you expect.
Going to the OP's original point. If the message is put with an expiry time of 60 seconds and is delivered to the target application in response to a get call 65 seconds after that then you have a problem. If you try and get the message (not browse it, not view it, but get it) after 65 seconds and nothing shows up you're fine.
The rest is theoretical.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 11, 2013 10:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| vishBroker wrote: |
yes. that is what I am trying to say - message is NOT discarded, even after expiry duration has elpased. |
Expired messages may exist in a queue for a while until they are discarded by the garbage collection process.
However, an expired message will never be delivered to an application.
If your expired messages are being successfully consumed from a queue, open a PMR.
Read a complete explanation here: https://www.ibm.com/developerworks/mydeveloperworks/blogs/aimsupport/entry/when_are_expired_websphere_mq_messages_removed_from_a_queue?lang=en
| Quote: |
| When a message’s expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or nonbrowse MQGET call occurs that would have returned the message had it not already expired. For example, a nonbrowse MQGET call with the MatchOptions field in MQGMO set to MQMO_NONE reading from a FIFO ordered queue discards all the expired messages up to the first unexpired message. |
_________________
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 |
|
|
| Andyh |
| Posted: Mon Feb 11, 2013 11:00 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
I ran a simple test on my system and demonstrated that the MQMD expiry time does decrease as expected (using amqsbcg).
If the MQMD expiry is not showing the true 'time to live' for the message on your system you should raise a PMR. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 11, 2013 11:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Andyh wrote: |
I ran a simple test on my system and demonstrated that the MQMD expiry time does decrease as expected (using amqsbcg).
If the MQMD expiry is not showing the true 'time to live' for the message on your system you should raise a PMR. |
Expiry times are approximate, not absolute. And, more importantly, the qmgr does not decrement the expiry value every 1/10th of a second for every message in every queue.
The real issue, the one that will determine whether to open a PMR, is: can your application successfully consume an expired message from a queue?
If the answer is YES, open a PMR.
The test:
1. Put a message with 60 seconds expiry value to a queue.
2. Wait more than 60 seconds.
3. Try to get the message from 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 |
|
|
| bruce2359 |
| Posted: Mon Feb 11, 2013 12:10 pm Post subject: Re: MQMD Expiry behavior |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| vishBroker wrote: |
But the issue is time is NOT decreasing as expected.
even if I check them message after 30 sec or 60 seconds, I still see the message on the queue with value as something like '573'. |
There is a difference between how something works, and exactly how something works.
In this instance, IBM manuals and other documents that describe how expiry works, but not exactly how expiry works.
All that you, your developers and managers need to understand is that when a message expires, it will not be delivered to an application.
How this works internally has changed over time, and will likely change in the future.
_________________
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 |
|
|
| vishBroker |
| Posted: Mon Feb 11, 2013 2:15 pm Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
Well, when I said, it is NOT getting discarded, I meant, it is being read.
I know, queue MAY show the message, but when tried to consume, it will NOT get consumed.
And, it was/is getting consumed after expiry elapses.
I did a quick test to capture the results
| Quote: |
16.58.57 2033 No messages in queue
16.58.03 2033 No messages in queue
16.57.56 Msg read from VK2121 length=1024 (data 1024 dlq 0 rfh 180 cics 0 ims 0)
16.57.11 Msg browse from VK2121 length=1024 (data 1024 dlq 0 rfh 180 cics 0 ims 0)
16.57.08 Connected to DEVMQPS01
16.56.30 Disconnected from queue manager
16.56.10 Msg browse from VK2121 length=1024 (data 1024 dlq 0 rfh 180 cics 0 ims 0)
16.55.51 Msg browse from VK2121 length=1024 (data 1024 dlq 0 rfh 180 cics 0 ims 0)
16.55.10 2033 No messages in queue
16.55.07 2033 No messages in queue
|
Above is o/p captured on RFH2 util.
1. I put a message with expiry as 60 ( value is shown as 600)
2. I browse the message and could see a message is there.
3. I tried to browse the message after 60 seconds, I still see a messag.
So far so good.
4. When I tried to READ the message after 1 minute, I got the message.
Which, I was expecting NOT TO happen.
Will check on our QA env which is AIX.
I guess, I need to open a PMR as suggested.
Btw - I tried to look for Expiry Interval property on the Windows. (regEdit) did not find it. Where should I look for it? |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
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
|
|
|
|
