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.

[jbarrez]

Do you have the job executor running? See http://activiti.org/userguide/index.html#jobExecutorConfiguration.
When using timers, the job executor activation property should be 'true'

[gerry_fisher]

Joram,

Thanks for your reply but I think you misunderstood my question.

The job executor is correctly set as <property name="jobExecutorActivate" value="true" /> in activiti.cfg.xml and all my timers are running as expected, as I can confirm from the ACT_RU_JOB table. However, once I shut down my JBoss server JobExecutor stops running, as expected.

So, how do I kick-start JobExecutor when I restart my server? I'm thinking there should be some method I can call, such as ManagementService.startJobExecutor(). Otherwise all my timers will not run after a server restart.

[jbarrez]

If your config is as above, the jobexecutor is activated when the engine boots.

Maybe your engine is lazily initialised? Best practice is to initialise it in eg a ServletContextListener (or something alike depending on the framework you like)

[gerry_fisher]

Joram,

I'm afraid my point is lost yet again.

Here's the scenario:

1. I've got a bunch of tasks, each with an attached timer running in its own thread;
2. I shut down my server thus killing off all my timer threads;
3. I restart my server.

How do I restart my timer threads?

Each timer has a record in table ACT_RU_JOB. When I restart my server I need to tell some piece of code to go read that table and start a timer thread for each record it finds.

At the moment the only way to restart all the timer threads is to complete one of the tasks that's got a timer attached to it. Once I do that I can confirm that the timers are now running because the job records in ACT_RU_JOB are now being updated whenever a timer fires an event.

The reference to lazy initialization is unclear. As far as I'm aware the engine is entirely passive, with the exception of any running timer threads. In any case, if the engine isn't passive, how do I activate it when my I restart my server?

Anyway, I've got another issue with timers for which I am going through your source code in order to find a solution. With a bit of luck I'll find solutions for both issues as I delve into the code.

[mproch]

Hmm…
What do you mean by "each with an attached timer running in its own thread"? Do you have your own timer mechanism?
Because activiti timers work in a different way - there is one thread, called jobAcquisitionThread which periodically checks if there are due jobs, and executes them (if there are any).
And this thread is started by JobExecutor.start() method, which in turn is called by ProcessEngineImpl constructor.
So if ProcessEngineImpl is created, with jobExecutorActivate=true, then timers should be fired at appriopriate times.

At least this is my understanding…

[gerry_fisher]

Maciek,

My understanding was that each timer was running in its own thread. I seem to be wrong in that respect. However, that misconception doesn't detract from my original question.

I've got jobAcquisitionThread running and my timers fire correctly. I shut down my server thus killing off jobAcquisitionThread. When I restart my server I need  jobAcquisitionThread to start running again. You say JobExecutor.start() is responsible for launching jobAcquisitionThread and, according to the documentation, "By default, the JobExecutor is activated when the process engine boots." The question then is: What method in the API do I call to boot the process engine?

[mproch]

If  jobExecutorActivate=true, then jobExecutor is started when ProcessEngineImpl is constructed, see:
https://svn.codehaus.org/activiti/activiti/trunk/modules/activiti-engine/src/main/java/org/activiti/...

How do you initialize your engine? If you use spring configuration more or less like this:

    <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
        <property name="dataSource" ref="dataSource"/>
        <property name="transactionManager" ref="transactionManager"/>
        <property name="databaseSchemaUpdate" value="true"/>
        <property name="jobExecutorActivate" value="true"/>
    </bean>

    <bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean">
        <property name="processEngineConfiguration" ref="processEngineConfiguration"/>
    </bean>
then there is small caveat: processEngine is not created when applicationContext is created…
It's only factoryBean that is created, but processEngine itself is created only when it's referenced - e.g. by invoking REST API, or in some other way. The way to force processEngine to be eagerly created is to add for example:

<bean id="runtimeService" factory-bean="processEngine" factory-method="getRuntimeService"/>

Don't know if this is your case - but I remember having some problems like you describe, and it was spring lazy initialization to blame.

[gerry_fisher]

Maciek,

Thanks for your reply. I shall explore your suggestion.

Restarting timers is such a self-evident requirement for an Activiti engine and I am surprised by the deathly silence from the team.

Once again, thanks.

[jbarrez]

Restarting timers is such a self-evident requirement for an Activiti engine and I am surprised by the deathly silence from the team.

The job executor (ie which execute timers is ALWAYS started when you have put your config on true, as Maciek explained).

As for our deathly silence, I already advised you to eagerly init your process engine in one of my first replies (as Maciek also advises in his last post):

Maybe your engine is lazily initialised? Best practice is to initialise it in eg a ServletContextListener (or something alike depending on the framework you like)