| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQMD Expiry behavior |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Mon Feb 11, 2013 2:56 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Expiry interval is a z/OS qmgr attribute only.
_________________
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: Tue Feb 12, 2013 4:07 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
The time at which an expired message is actually removed from the queue is not guaranteed, but the Expiry field in the MQMD returned on any MQGET should accurately reflect the remaining 'time to live' for a message.
If this were not the case the message could not be propagated through the system while maintaining the correct expiry behaviour.
If you can demonstrate an MQGET where the MQMD Expiry field does not accurately reflect the remaining time to live then an APAR will be accepted. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 12, 2013 5:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 12, 2013 9:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
I don't think the OP is having a problem with messages not being returned, or "phantom" messages contributing "falsely" to q depth.
If I read it correctly, he says he can see the message and the MQMD Expiry value is not decrementing, which would be a shocker if actually the case.
His captures of amqsbcg output does seem to confirm that 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 12, 2013 10:16 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 12, 2013 10:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I suspect that there is a confusion between 60 seconds and 600 seconds. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 12, 2013 11:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
I don't think the OP is having a problem with messages not being returned, or "phantom" messages contributing "falsely" to q depth.
If I read it correctly, he says he can see the message and the MQMD Expiry value is not decrementing, which would be a shocker if actually the case.
His captures of amqsbcg output does seem to confirm that |
I would be surprised if expiry was updated frequently. If there were one million messages in queues, then mq would be doing little more than calculating expiry.
Messages are consumed from buffers, not from disk directly. It would impose lots of I/O to update expiry on disk.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Feb 12, 2013 12:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
His amqbcg output shows the Expiry value, presumably in tenths of a second, dropping by a value of only 17, after several minutes time have passed.
If the time stamps are accurate, if the message is in fact the same one (MsgID and CorrelID are the same), then this very odd.
Unless the system clock is being reset, I wouldn't be able to explain this.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 12, 2013 2:56 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Waiting for someone from Hursley to shed some light on how and when expiry is calculated...
_________________
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: Tue Feb 12, 2013 3:46 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
This if from a 2007 Hursley post: http://hursleyonwmq.wordpress.com/2007/08/21/what-happens-to-websphere-mq-if-the-time-changes/
| Quote: |
Expiring messages
Consider a message which has a specified time-to-live after which it becomes eligible to be discarded (if it has not already been got from the destination queue). In these cases, the queue manager stores the time that the message arrives, and uses this to perform comparisons with the current time to identify if a message should expire.
If the system clock changes after such a message is put, then it is possible that messages may be expired too soon, or not expire when intended. This may cause a problem for applications which rely on message expiry.
With persistent messages, the stored arrival time will be written to disk and will be restored after the restart of a queue manager. Restarting a queue manager after changing the system time will therefore not resolve any such problems.
|
_________________
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: Wed Feb 13, 2013 4:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right, so again let's look at what can be known about a message.
The message has a put time and put date. The message also has a number of tenths of a second attached as the expiration time.
There's no particular reason to ever decrement the expiration time.
One can substract put date/time from the current date/time and see if that is larger in tenths of a second than the expiration.
If it is, it is clear that the message has expired.
It is possible that applications can choose to decrement the expiration time, including channel agents, to reflect that they have held the message "off of queue" for a certain point so that the *new* put/date time is still accurate for the original expiration. because when a message gets read from one queue and put to another, there is of course a new put time.
I do not say this is what is being done, I merely say that there's no specific reason that I am aware of to handle it any other way. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 14, 2013 7:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| vishBroker wrote: |
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). |
Dude, the message content is different between these 2 messages. So even though you have the same Message ID, the same Correl ID, the same Put/Date time, these are not the same message. All those fields can be set by the putting application. You have 2 messages in the system with the same Message ID  . That explains the Expiry being odd - its not odd, its 2 seperate messages each with their own Expiry.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 14, 2013 8:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
So, the OP mislead us by describing this as putting a (single) message into a queue...
I'm shocked.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Feb 14, 2013 10:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| bruce2359 wrote: |
So, the OP mislead us by describing this as putting a (single) message into a queue...
I'm shocked. |
Not intentionally, I would guess.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Feb 14, 2013 11:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| PeterPotkay wrote: |
| Dude, the message content is different between these 2 messages. So even though you have the same Message ID, the same Correl ID, the same Put/Date time, these are not the same message ... |
These could be two different messages, or it could just be a really bad copy-paste job. Some of the lines in the first message are chopped off at the end (note the missing trailing quote character), but are otherwise identical. Neither output is displaying the entire 1204-byte message, but they are truncated at different points. The hex bytes that are there are identical though. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
