After unexpected server time shift WPs will not fully start
Article ID: 422916
Updated On:
Products
Issue/Introduction
After an unexpected time shift forward on a server and a time shift back to correct the situation, a restart of WPs does not work. The first WP that starts up will not bind to PWP port or become the PWP.
In this case, a customer's server shifted forward 2 hours and workflows started running based on the server time (2 hours earlier than they should). The WP that starts up is unable to become PWP and there are no other processes running. The WP log does show other WPs in the process list:
AUTOMIC#CP001 JCP SERVER 59334 2025-12-14 12:32:41.257 2025-12-14 12:32:42.407
AUTOMIC#CP002 JCP SERVER 59379 2025-12-14 12:33:01.147 2025-12-14 12:33:02.300
AUTOMIC#CP003 JCP SERVER 59388 2025-12-14 12:33:11.013 2025-12-14 12:33:12.153
AUTOMIC#CP005 REST API SERVER 63196 2025-12-14 12:26:10.247 2025-12-14 12:26:10.247
AUTOMIC#CP006 JCP SERVER 63212 2025-12-14 12:25:56.887 2025-12-14 12:25:58.037
AUTOMIC#CP007 JCP SERVER 63220 2025-12-14 12:24:06.517 2025-12-14 12:25:57.727
AUTOMIC#CP008 JCP SERVER 63235 2025-12-14 12:24:16.863 2025-12-14 12:25:58.060
AUTOMIC#CP009 JCP SERVER 63244 2025-12-14 12:24:26.727 2025-12-14 12:25:57.827
UC4PEJWP001 PWP SERVER 2270 2015-11-16 17:12:10.000 2025-12-14 14:14:06.000
AUTOMIC#P008 JWP SERVER 63184 2025-12-14 12:23:25.287 2025-12-14 12:26:17.027
The LastUpdateTime entry in the table is in the future
Environment
Version: all
Cause
The PWP is never removed from the MQSRV table because the last updated time is in the future and the product is designed to only work in real time
Resolution
Work with a DBA to delete the entries from the mqsrv table - if processes are still running, they will add themselves back in.
Feedback
