Symptoms
The parent process gets to the IPC event, but the child process never does.
Diagnoses
The K2Server and the SQL Server hosting the K2DB, was not on the same time-zone. In this scenario the K2Server was one hour ahead of the SQL server.
Here is what is happening in the background...
- The Parent process is started and IPC entry is created as well as a IPCAsync entry. (Which will start the Child process)
- IPCAsync entry is created with a time stamp when it should fire, time stamp is coming from K2 Server so it 1 hour ahead in time compared to SQL time.
- Result here is the IPCAsync entry will sit in the table until the time has "expired". Here, it will take 1 hour for the child process to start.
- Once the child is completed, another IPCAsync entry is created to go back to the parent process to continue on its way. This is for all "Synchronous" IPC events. (Where the parent process should wait for child process to complete.)
- Again, the entry will be created using the K2Server time, and once again there will be a delay of 1 hour until it will fire to continue processing the parent process, and ultimately complete.
Resolution
After placing the K2Server and SQL Server in the same time-zone, the IPC child processes started and completed as expected. As things stand now, this is "by design". The ticket was routed to the LABS support team and we have logged the following feature requests in TFS.
1.) For the "immediate future" we have logged a documentation enhancement request. The K2 documentation will be updated to make this a requirement. We will add clear notes in the docs stating that if your K2Server and SQL server is NOT in the same time-zone, that you will have this issue with IPCs, all Escalations, scheduled tasks and start rules.
2.) The "Preferred fix" would be to have the K2 Server take this "offset" into consideration (time diff between K2 Server and SQL) when creating IPCAsync and Async entries in the DB. This will ensure that there is no delay on when they should fire. (We need to "date" IPC entries in these tables to make sure that the first IPC entries made, gets processed first.)
3.) Lastly, we can have the installer check and warn if there is time difference between K2Server and SQL. We can display a warning message to the end-user stating that you will see delays with IPCs, all Escalations, scheduled tasks and start rules. If the time-zones get "out of sync" somehow post-installation, we will write a warning message in the K2HostServer log files. (This might not be needed if the "Preferred fix" is implemented.)
