Problem with time duration event

Camunda 7 Topics Discussion & Questions
1

Hello,

i’am having problems in order to define a simple timer event, that is waiting 10 seconds for testing purposes. So the token comes in, has to wait 10 seconds and thats it. I have read:

  1. https://docs.camunda.org/manual/7.6/reference/bpmn20/events/timer-events/
  2. and https://en.wikipedia.org/wiki/ISO_8601#Durations

I have defined “PT10S” - timer duration event. But i don’t get what i want. Could you help me please?

Thanks a lot in advance.

best regards,
Andy

2

Hi @Andy
Please have a look at this post
Timer not working in Camunda 7.5.3 using PT3S

3

If you’re needing precision, 10 seconds is too short a duration. The Camunda timer is driven by a job executor. And this executor service I think has a default of around 15seconds. Setting a BPMN timer means that you’re queuing up a sort of “batch job” request to be picked up by the executor the next time it starts-up.

These timer events are essentially stored in a table. When the executor runs, the timer configuration (i.e. when to start, etc) is picked up, evaulated, and then launched (if it’s due for execution).

This means that a timer set to 10seconds may start in the next window set by job-executor configuration - which isn’t necessarily within 10seconds measured from the token instance arrival at the timer element.

Another point here is that these timer event instances have an affinity to their BPMN model’s version. This means, that if you’re in a cycle of test-revision-redeploy, a yet-to-fire timer event will follow a path defined by the model’s previous version. Slightly off from a developer’s expectations (well, for me at least when I forget this small detail).

What I do during testing is to first clear out all the tokens - camunda offers some good house-keeping API calls for this purpose. Or, if you’re using the H2 database, just simply delete it prior to initiating a full-cycle test. But, don’t forget to start the test with a redeployment.

A fall-back option I’ve been trying out is to replace the timer with a BPMN message catch event. Though they’re not expressing the model’s design intent (i.e. this is a timer), they are a little more flexible given you can drive them ad hoc, externally. This means, you can start-up a process instance, and then drive this model via directed events from an external source:

  1. check for token’s arrival
  2. verify model state
  3. send message event

Noting here… that I think Camunda now provides a method of forcing a timer event to fire much in the same way a BPMN catch-message behaves (this needs to be verified - but I think I ran across a utility that provides this exact feature).

4

Thank you for your detailed answer and your alternative idea. I’am working with the OSGI blueprint extension and i figured out, that the event is never fired. In the spring environment it is working fine as i want. So i would like to figure out, what the problem with the osgi version is. FOr that it would be nice to understand how the official supported version is working with a duration timer event. Please correct me if i’am wrong:

Let’s assume i have defined a timer-duration task with PT1M in order to wait 1 minute from now on. What happens?

  1. The token arrives
  2. The jobexecutor creates a timer-job at time t and a dueDate t+1 minute and references it with the processinstance.
  3. If the DueDate is reached a method is called to inform the engine to procceed. In which class is that “notify” method? I would like to check if OSGI-version is calling that method too.

For someone, who is interested see this issue.

Thanks a lot for your help :slight_smile:

5

Assuming you didn’t see anything in the logs - immediately suspicious of the bundles not correctly providing resources to the rest of the application.

First going after to potentially easy fixes - ruling out basic stuff:

  1. simply re-initialize the camunda database. Drop the DB and re-generate.
  2. Make sure the DB is functioning correctly. Create/register the timer and verify in the DB.
  3. Make sure Camunda runtime isn’t throwing any internal exceptions. Turn logging way up and test your use-case.
  4. Add more logging to Camunda sources. I’d add a few extra log outputs (per timer event) to see if there’s an exception getting thrown and then buried somewhere.

This is what I’ve done to help resolve OSGi/Blueprint issues:

  1. first allow access to everything. Then, maybe dial it back if that’s the problem.
  2. add some methods the help track BluePrint startup and service registration:

example:
from a tutorial I wrote a while ago - using Apache Aries.

@Override
public void startUp() {
      System. out.println( "*** ColorManagerImpl.startUp()");
      
}

@Override
public void onRegisterService(ColorManager colorManager, Map props) {
      System. out.println( "*** ColorManagerImpl.startUp()");
      
}

@Override
public void onUnRegisterService(ColorManager colorManager, Map props) {
      System. out.println( "*** ColorManagerImpl.onUnRegisterService()");
      
}

@Override
public void referenceBind(ColorManager colorManager) {
      System. out.println( "*** ColorManagerImpl.referenceBind()");
      
}

@Override
public void referenceUnBind(ColorManager colorManager) {
      System. out.println( "*** ColorManagerImpl.referenceUnBind()");
      
}
6