| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Expiry field - system clock |
« View previous topic :: View next topic » |
| Author |
Message
|
| ydsk |
 Posted: Thu Dec 08, 2005 9:42 am Post subject: Expiry field - system clock |
 |
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Can someone please tell me when we set Expiry in the MQMD of a message in a client program, would it be the client machine's system clock or the queue manager's system clock that would be used for all calculations ?
Please don't guess and reply to this post only if you know this for sure.
Thanks in advance. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Thu Dec 08, 2005 9:48 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| The clock of the machine where the message resides. If you'll check out the application programming reference manual, it discusses the fact that the expiry is the 'message lifetime' in tenths of a second. It then goes into a discussion on the decrementing of the value. |
|
| Back to top |
|
|
| ydsk |
| Posted: Thu Dec 08, 2005 10:31 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Can you please point me to the page # of the manual where it says it would be the clock of the client machine ? I couldn't find that piece of information anywhere.
Thanks. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Dec 08, 2005 11:25 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| when we set Expiry in the MQMD of a message in a client program, would it be the client machine's system clock or the queue manager's system clock |
Neither. The field is set in 1/10ths of a second. This is then decremented until it hits zero. At that point, the message expires.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Thu Dec 08, 2005 11:35 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
As bower5932 said, the only clock that will ever be used to decrement expiry time is the clock of the machine where the message is currently residing.
This means that:
1) if a message is put to a local queue from an application running locally on that server, the expiry time is decremented beginning at the time the message is placed on the queue;
2) if it is put from a client to a local queue, then the same is true; network time will not be counted as the program calls are actually run on the server side;
3) if it is put to a remote queue on machine A destined for a queue on machine B, both clocks will be used. Time will be decremented from the expiry field for the duration of time it sits on the xmitq on machine A, then once delivered to the receiving end, time will be decremented whatever value is left in the expiry field there. The MCA can also decrement the time, "if significant".
| 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. |
So in short, depending on your message flow, multiple clocks can decrement the value of the Expiry field.
Hope this helps.
Steve |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Dec 08, 2005 11:38 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Very good comments thus far....Its important for people to realize that machine clocks do not need to be synchronized for expiry to work properly.
_________________
-wayne |
|
| Back to top |
|
|
| ydsk |
| Posted: Thu Dec 08, 2005 3:11 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
I am not sure whether I agree with the statement 'machine clocks need not be in sync'.
The time is calculated as UTC, this is a value that is an offset from an arbitrary date (I think it is from 1970) adjusted with GMT. So for example, if current time is 12:30 PM on Dec 2nd 2005, it will be the number of seconds elapsed from 1970 right now. So for example a message travels from Machine A to Machine B:
1) If Machine A’s clock is accurate, the time calculated will be correct. Assume we got a put time of 1000 (seconds in UTC, i.e. offset from the 1970 date) and we set expiry time to be 2 seconds. Lets assume it takes 1 sec for the message to reach machine B.
2) If Machine B is also accurate and in sync with A, then the current time will be 1001 as per UTC when the message reaches B. If an application gets the message at that second, Queue Manager will return the message to the app, as it has not expired.
3) If Machine B is behind (lets say by 10 seconds), the current time returned will be 991 (10 – 1 sec for the message to get there), and the application will still get the message as it has not expired. B now thinks that it still has 9+2 seconds left to expire.
4) However if Machine B is ahead (again say by 10 seconds) the current time returned will be 1010, so the message has already expired by 8 seconds, the moment it arrives on the queue manager. Hence the application will not get this message.
This is a reason why the clocks need to be in sync, or at least close, or the expiry time needs to take into account the difference in time settings.
Are the above arguments reasonable ? If not, can someone please explain why.
Thank you all. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Dec 08, 2005 4:27 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Are the above arguments reasonable ? If not, can someone please explain why. |
No. The expiry is a count of how many 1/10ths of a second must elapse before a message expires. This count is not tied to any timestamp contained in the message.
<OverSimplification>When the message arrives on a Queue, MQ knows the local time of that event. When the message leaves the Queue, MQ again know the local time of that event, and hence how long it was on that queue. The expiry count is decremented accordingly.</OverSimplification>
In a similar fashion, when a message is in transmission, each side of the transmission uses it's own local clock to determine how long it took. Not the difference in time between the two, different, clocks.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Dec 08, 2005 8:45 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
I am not sure whether I agree with the statement 'machine clocks need not be in sync'.
|
Why? MQ is designed to be asychronous. You may have no control over where the message ends up, so how can you possibly expect the clocks to be in sync?
Don't think of expiry as a wall clock time, think of it as 'number of ticks to live'
 |
|
| 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
|
|
|
|
