Timer jobs not running after restarting my server.

[gerry_fisher]

Can anyone please advise me on how to get my timer jobs running again after restarting my server.

Essentially, my application (which contains Activiti) is deployed as a .war file on JBoss.

The interesting thing is this: as soon as I complete one of the tasks that has a timer attached, the JobExecutor 'kicks in' and all the other outstanding timers in the ACT_RU_JOB table get updated.

[gerry_fisher]

For the benefit of anyone reading this thread and looking for a non-Spring/non-xml solution all you need is:


public void startActivitiEngine() {
  ProcessEngineConfiguration.createProcessEngineConfigurationFromResource("activiti.cfg.xml")
         .setProcessEngineName("activiti-engine")
         .buildProcessEngine();
 
  logger.info("Activiti engine started.");
}

We've placed the method inside a class that gets called by our bootstrap framework which is responsible for restarting a variety of services whenever we restart the server.

[ronald_van_kuij]

For the benefit of anyone reading this thread and looking for a non-Spring/non-xml solution all you need is:


public void startActivitiEngine() {
  ProcessEngineConfiguration.createProcessEngineConfigurationFromResource("activiti.cfg.xml")
         .setProcessEngineName("activiti-engine")
         .buildProcessEngine();
 
  logger.info("Activiti engine started.");
}

We've placed the method inside a class that gets called by our bootstrap framework which is responsible for restarting a variety of services whenever we restart the server.

How did you get the engine running in the first place? If you do not do something like you describe now, it won't run at all.

[mproch]

Well, I think it is actually possible.
If you look at https://svn.codehaus.org/activiti/activiti/trunk/modules/activiti-engine/src/main/java/org/activiti/... you'll see that ProcessEngines.getDefaultEngine() will actually create processEngine if it's not already created… - so this is lazy initialization that Joram is talking about. And if you don't call it explicitely during bootstrap, it will be called e.g. when you invoke some REST API - that's why jobExecutor was started only when someone displayed tasks page.

I think this behaviour indeed can be somewhat confusing - starting engine more or less automagically based on configuration details.

[ronald_van_kuij]

You mean he was lucky initially because he did some requests to the api himself? That kind of lazy… Ok, makes sense

[gerry_fisher]

Maciek, Ronald,

Thanks for both your comments. I guess I was doing lazy initialization all along without thinking about it. Just create a task and the engine gets started as a consequence. Therefore, if my server went down and then came back up again, the only way my engine would start running again was if I created another task. But that wasn't satisfactory since task creation is a random user event whereas I needed the JobExecutor to start running straightaway.