JobAcquisitionThread and JobExecutor

[pganga]

Hi Guys,
We are trying to replace the default job executor for a custom one that will use spring and the application server thread pool (commonj Work Manager). So we don't use any unmanaged threads.
Reviewing the code we notice that is using another unmanaged thread the one polling for available jobs (JobAcquisitionThread).
It is there a way to replace that component easily?
Which will be the best strategy to follow in this case?.

Thanks in advance.

[heymjo]

Hello Heiko,

I have tested your CommonJ interface code on Weblogic 10.3.4 and it works fine. I created an application level workmanager, plugged it in your JobExecutor via the jndi ref, then created a process with an async service task and all is executed fine.

The thing i cannot judge though from your code is if there are any websphere specific semantics in it with regards to the way you schedule jobs for execution. Do you have an idea about this ?

thanks

[EDIT] it seems that there are some issues though, threads are getting stuck. Going to investigate and load test this.

[bardioc]

Hello Heiko,

I have tested your CommonJ interface code on Weblogic 10.3.4 and it works fine. I created an application level workmanager, plugged it in your JobExecutor via the jndi ref, then created a process with an async service task and all is executed fine.

The thing i cannot judge though from your code is if there are any websphere specific semantics in it with regards to the way you schedule jobs for execution. Do you have an idea about this ?

thanks

Hello,

actually not besides the usage of the UOWTransactionManager, which is Websphere specific, the code I wrote should work with all application servers that rely on WorkManagers. A caveat here is, that the WebSphereProcessConfiguration needs to extend the class SpringProcessConfiguration. That is necessary for the Transaction Manager to work correctly. However, if the API of Activiti would open the possibility to 'setJobExecutor()', which is currently not open API, one could simply remove the configuration object and provide a WorkManagerJobExecutor().

Great to hear, that this works for WebLogic too, so I will add another section to my upcoming chapter for Application Server support for the Activiti Documentation.

Thank you,

Heiko

[heymjo]

I am seeing this in the weblogic console (the CommonJ is just a rename from the original Websphere* classes)


"[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock java.lang.Object@1eac46a TIMED_WAITING
        
java.lang.Object.wait(Native Method)         
org.activiti.engine.impl.jobexecutor.AcquireJobsRunnable.run(AcquireJobsRunnable.java:101)                        my.app.commonj.CommonJJobExecutor$JobAquisitionWork.run(CommonJJobExecutor.java:74)         
weblogic.work.j2ee.J2EEWorkManager$WorkWithListener.run(J2EEWorkManager.java:183)         
weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)         
weblogic.work.ExecuteThread.run(ExecuteThread.java:176)

Looking around a bit this seems harmless though:

In addition to reporting STUCK for requests that simply take a very long time, the stuck thread detector can mistakenly assume a thread is stuck if the thread is in a continuous loop doing real work – for example servicing many requests in succession without ever returning to the thread pool.

Since this is exactly what the AcquireJobsRunnable is doing we can assume it is a non-event. A modest load test also did not reveal any problems, i'll report back in case anything appears.

[heymjo]

Hi,

Just a quick question still on this. IIUC the purpose of AcquireJobsRunnable, would this not be something that the commonj TimerManager could/should do ? The TimerManager schedules jobs (= classes implementing TimerListener) to run at a fixed interval in a 'managed' fashion.

      InitialContext ic = new InitialContext();
      TimerManager tm = (TimerManager)ic.lookup("java:comp/env/tm/default");
      // Execute timer every 10 seconds starting immediately
      tm.schedule (new MyTimerListener(), 0, 10*1000);


cheers

[sebastian_s]

Bringing this up again:

Since ACT-34 has been resolved what's the matter with adding activiti-websphere as an additional module? Maybe it should be generalized and renamed depending on the experiences Jorg made using it on WebLogic.

I could not find a JIRA issue for this topic. Please point me to the existing JIRA issue if existent. Otherwise I will create a new JIRA issue for this subject.

[heymjo]

+1 for creating 'activiti-commonj' module

[melentye]

Hello all together

fyi: it is now possible not to extend EngineConfiguration anymore but instead inject a custom jobExecutor it using activiti.cfg.xml, I believe this is a result of ACT-34


    <bean id="processEngineConfiguration" class="org.activiti.cdi.CdiJtaProcessEngineConfiguration">
        <property name="transactionManager" ref="transactionManager" />
        <property name="dataSourceJndiName" value="XXX" />
        <property name="databaseSchemaUpdate" value="false" />
        <property name="databaseType" value="postgres" />
        <property name="jobExecutor" ref="commonjJobExecutor" />
        <property name="jobExecutorActivate" value="true" />
        <property name="transactionsExternallyManaged" value="true" />
    </bean>

    <bean id="commonjJobExecutor" class="org.activiti.commonj.CommonjJobExecutor">
        <property name="workManagerJndiName" value="java:comp/env/wm/ActivitiWM" />
    </bean>
Heiko, in the first reply you've mentioned that you have a version of JobAcquisitionThread implemented with TimerManager but it isn't in the attachment, would you mind sharing it with us?

The only issue I have seen under WL so far is the reports on stuck WorkManager threads (see heymro's comment) which are harmless and can be suppressed and the only stuck thread is actually JobAcqusitionThread running continuously in WorkManager

And of course another +1 for creating an activiti-commonj module for proper application server deployments.

regards,
Andrey