nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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.

Find more posts tagged with

Comments

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/engine/impl/ProcessEngineImpl.java

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

<br>&nbsp;&nbsp;&nbsp; <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <property name="dataSource" ref="dataSource"/><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <property name="transactionManager" ref="transactionManager"/><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <property name="databaseSchemaUpdate" value="true"/><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <property name="jobExecutorActivate" value="true"/><br>&nbsp;&nbsp;&nbsp; </bean><br><br>&nbsp;&nbsp;&nbsp; <bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <property name="processEngineConfiguration" ref="processEngineConfiguration"/><br>&nbsp;&nbsp;&nbsp; </bean><br>

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)

gerry_fisher

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

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

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/engine/ProcessEngines.java 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.