AnsweredAssumed Answered

Timestamp issues

Question asked by dan1 on Jul 19, 2016
Latest reply on Jul 20, 2016 by dan1
Hi,

I have the following setup:

Activiti 5.21
Tomcat 8
Java 8
Postgresql 9.4.1208

I'm having issues with the timestamps stored in ACT_RU_TASK and ACT_HI_ACTINST by Activiti Engine. The timestamp provided by the engine is roughly a day behind the system time. Both Java and Postgres have the correct time. Activiti logs also have the correct time. However, timestamps generated by getClock().getCurrentTime() are wrong. And its stuck. After starting up tomcat and deploying the app, getCurrentTime() always returns the same value. So all my user tasks start and end at the same time. And of course, timers have issues.

I created a simple progress called Timestamps with a groovy script followed by a user task. Here is the script:


println "Entering Groovy Timestamp Script…"

def javaDate = new java.util.Date();
println "    Java date:     " + javaDate.toString()

def activitiDate = execution.getEngineServices().getProcessEngineConfiguration().getClock().getCurrentTime();
println "    Activiti date: " + activitiDate.toString()


If I start that process twice in a row, here is the output:


Entering Groovy Timestamp Script…
    Java date:     Tue Jul 19 06:47:23 EDT 2016
    Activiti date: Mon Jul 18 06:46:31 EDT 2016
Entering Groovy Timestamp Script…
    Java date:     Tue Jul 19 06:47:36 EDT 2016
    Activiti date: Mon Jul 18 06:46:31 EDT 2016


Notice that the Java Date is correct and advances by several seconds. While the Activiti date is roughly a day behind and is stuck. When I complete the 2 user tasks (one per run) sometime later, the end timestamps are the same value too. Effectively, the engine is always generating the same incorrect value for date. In other words, ACT_HI_ACTINST START_TIME_ and END_TIME_ values are equal to each other and the same across all runs.

I wrote another little process called Reset Clock. Its a groovy script that calls getClock().reset().


println "Resting engine clock to match current date."
def javaDate = new java.util.Date();
println "    Current date:     " + javaDate.toString()

def clock = execution.getEngineServices().getProcessEngineConfiguration().getClock()
clock.reset();
def resetDate =  clock.getCurrentTime();
println "    Reset date:        " + resetDate.toString()


Here is output which works as you'd expect:


Resting engine clock to match current date.
    Current date:     Tue Jul 19 06:47:52 EDT 2016
    Reset date:        Tue Jul 19 06:47:52 EDT 2016


Now if I go back to the original Timestamps process, things start to work as expected:


Entering Groovy Timestamp Script…
    Java date:     Tue Jul 19 06:48:28 EDT 2016
    Activiti date: Tue Jul 19 06:48:28 EDT 2016
Entering Groovy Timestamp Script…
    Java date:     Tue Jul 19 06:48:36 EDT 2016
    Activiti date: Tue Jul 19 06:48:36 EDT 2016


And when I complete the associated user tasks, they have correct timestamps at the end (i.e. ACT_HI_ACTINST is correct).

Looking through the code and many similar issues on the forum, I'm at a loss for what is going on. Seems that others have had similar issues:

https://forums.activiti.org/content/wrong-date-activiti-explorer-handle-vacation-request
https://forums.activiti.org/content/newbie-activiti-clock-configuration
https://forums.activiti.org/content/boundary-event-subprocess-not-firing
etc.

My current work around is to uncomment out all the xml in activiti-custom-context.xml. Then add a bean for engineClock which is DefaultClockImpl. Set that in the clock property of the processEngineConfiguration. And finally, schedule a one time task to invoke the reset method on the engineClock. See attached file.

My solution is a hack. Any clues how to solve this a better way?

Thanks,
Dan

Outcomes