•MPS Laptops were experiencing errors beginning at 01:00 (before setting clocks back to Central Standard Time). “TIMESTAMP OF COMMAND FROM CLIENT LATER THAN CURRENT SERVER TIME”
Have any other agencies reported this? What can we do to prevent it from happening again?
Yes In Boston we experienced the same issue during the last hour of Eastern daylight time.MPS error “TIMESTAMP OF COMMAND FROM CLIENT LATER THAN CURRENT SERVER TIME”
When the clocks switched to Eastern Standard Time the problem fixed itself. By the time I was notified everything was working fine. We are still looking into it and don’t have any answers yet
Can one (or both) of you post the MPS and MDT logs from that time period? I don't have a theory yet on why this would happen, but maybe there is a clue in the logs.
I have posted our logs to SR # 1-1772225921
I posted some logs under SR 1-1797393001
Thanks for your reply.
We are runnung CAD 9.2 MR 5. Are you running the same?
No problem it helped big time to know I wasn't the only one stuck in the wrong time zone
We are running 9.2 MR3
Thanks. We've taken a look at some logs and I think there will end up being a code change on the server side.
Change Request Filed
Product Defect 1-TQA96N has been associated to SR RowId: 1-TB4Y9T. The CR is currently statused as Filed / CCB Review. Association made by MBILLQUI
Hexagon told us that restarting the MDTSVR, MDTADMIN, RPTGEN, UEDELTA, and MDTSVR_UEDELTA services would be a workaround for this.
I set up a scheduled task to restart the services below at 01:04, prior to the time change using the ISMRequest application. It ran as planned, evidenced by the logs.
The MPS users experienced problems one hour before the time change and were still having problems after the services were restarted and they restarted MPS.
I was called out and restarted the services manually at 1:45 AM, prior to the time change. This also did not resolve the problem as it was indicated it would.
The issue stopped at 02:00 (01:00) when the time changed.
Did anyone else have this issue again and find it was not resolved by restarting the services above?
What version are they running? If it is 9.3 MR4, there is an I/MDT patch for that: 1-1MGH211. (It was also fixed on 9.4 Q2, 2018 under 1-TQA96N). I don't immediately see patches for other baselines.
We will be upgraded to 9.4 Q3 by next November, though. I was just wondering if anyone else was told that an I/MDT services restart would work as a workaround, and if it did.
Please sign in on the right menu to comment.
If you do not have an account, please Join now.