| Author |
Message
|
| henry_chuo1 |
 Posted: Tue Dec 15, 2015 6:24 pm Post subject: how to get timestamp of putting msg into queue |
 |
|
Novice
Joined: 13 Nov 2014
Posts: 11
|
Hi all,
We have a client server application using MQ as middleware. Given that client clocks are not synced with server, is there any way I can get the timestamp that a msg is put into the queue in terms of central server clock? thanks in advance.
Henry |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Tue Dec 15, 2015 7:38 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
The call that puts a MQ message returns the PutDate/PutTime in the MQMD. This is the system clock time on the server where the qmgr is running. There is no other time available.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 15, 2015 9:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| gbaddeley wrote: |
| The call that puts a MQ message returns the PutDate/PutTime in the MQMD. This is the system clock time on the server where the qmgr is running. There is no other time available. |
Not quite. It is the system clock time on the server the queue manager the message was put to is running.
As you have notices this might not be the queue manager the message is getting consumed on and the clocks might differ across your servers.
Use NTP protocol to sync your clocks across your estate.
Or suffer the clock difference between your servers... Eventually the message could get consumed before it was put (clock difference)... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| henry_chuo1 |
| Posted: Tue Dec 15, 2015 11:23 pm Post subject: |
|
|
Novice
Joined: 13 Nov 2014
Posts: 11
|
It looks like JMSTimestamp and JMSExpiration use client PC clock while JMS IBM PutTime use server clock on which queue manager is running.
Then does it means that the message will expire in one minute instead of 3 mins (value I set in setTimeToLive() ) as server clock faster than client by 2 mins? thanks
2015-12-16 15:12:18,517 DEBUG SYS - JMSTimestamp:2015-12-16 15:10:03.539
2015-12-16 15:12:18,517 DEBUG SYS - JMSExpiration:2015-12-16 15:13:03.539
2015-12-16 15:12:18,517 DEBUG SYS - JMS_IBM_PutTime:07121851
2015-12-16 15:12:18,517 DEBUG SYS -
JMSMessage class: jms_text
JMSType: null
JMSDeliveryMode: 1
JMSExpiration: 1450249983539
JMSPriority: 4
JMSMessageID: ID:414d5120465443534430312020202020565bea3520057c2f
JMSTimestamp: 1450249803539
JMSCorrelationID: 005
JMSDestination: queue:///C2P.SESS.E01
JMSReplyTo: null
JMSRedelivered: false
JMSXAppID: WebSphere MQ Client for Java
JMSXDeliveryCount: 1
JMSXUserID: mqcpclt
JMS_IBM_Character_Set: UTF-8
JMS_IBM_Encoding: 273
JMS_IBM_Format: MQSTR
JMS_IBM_MsgType: 8
JMS_IBM_PutApplType: 28
JMS_IBM_PutDate: 20151216
JMS_IBM_PutTime: 07121851 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 16, 2015 5:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
AFAIK TTL or Time To Live is a duration and not a time stamp. This makes your question irrelevant as the duration would be the same regardless if looked at from the client or the server...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| henry_chuo1 |
| Posted: Wed Dec 16, 2015 5:45 pm Post subject: |
|
|
Novice
Joined: 13 Nov 2014
Posts: 11
|
| Yes, ttl is a duration, but somehow queue manager should have reference timestamp or it is a just counter which count down to 0 when msg is put into the queue? Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 16, 2015 8:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| henry_chuo1 wrote: |
| Yes, ttl is a duration, but somehow queue manager should have reference timestamp or it is a just counter which count down to 0 when msg is put into the queue? Thanks. |
If you look at the Interface, I believe it is a long. This is a counter counting down to 0 in milliseconds, according to the JMS 1.1 Java EE 7 documentation of the producer.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 17, 2015 6:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm confused. What does Time To Live have to do with when the message was put?
If the desire is to have the PUTTIME/PUTDATE be relevant to a central clock, then the queue manager server should be configured to use NTP.
Not sure how this is any more complicated than that?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 17, 2015 9:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
Depends on whether you look at TTL (Time to live) as a duration or as a timestamp. If it is a timestamp the question would have been relevant.
As it is a duration, the question should be irrelevant unless a timestamp is applied against the current time, source time and duration...
Which means that if received on a server where the clock is early you could expire messages that should still be alive...
Best synch up your servers to a local NTP server, and synch that one up with a nearby atomic clock (Denver, Paris, etc...)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
