Refactor JobExecutor (ACT-34)

[ronald_van_kuij]

To continue the discussion from ACT-34 here seems better. The Jira should only contain conclusions (imo) or concrete directions.

The 'async workbeans' solution in WLS and Websphere seems 'older' than CommonJ. Strange then that it CommonJ refers to a withdrawn jsr and it mentiones that it is integrated in JSR-236. Which did not produces any results as far as I can see. The only reference to CommonJ is that it is input for the spec. From reading this CommonJ document it seems that one of the intentions was to get things decoupled from JCA (where the javax.resource… comes from). Ok, so much is clear now.

Basically I still hope it it still possible to share one container managed threadfactory (from a workmanager?) in multiple 'normal' ThreadPoolExecutors and that there is a similar thing for WLS (the most used appserver? In sold licences?)

Regarding using the timer fuctionality of either java.util or commonj, I have my doubts. Most of the timers will be relatively a long time from 'now'. So with lots of process instances, the behaviour will become difficult. The queue can be full but there could be timers in there which are beyond one that needs to be inserted now. Since timers are *not* concidered time critical, I think a normal queue where every x seconds query takes place to retrieve timers that are to be executed within x seconds is still a good option. The solution is then no different from normal queues.  Even putting the result of this query in a scheduled pool yields notthing I think. Well, maybe we could query every x seconds and query for timers in the period of 2*x seconds, so there is some overlap, but have the scheduled executor prevent the jobs to be executed to early. But that is an optimization…

[tombaeyens]

Ronald,

Could you summarize what the conclusions are you have drawn so far and where the open issues are?
I would like to understand in particular:

* Standalone usage: which dependencies will be introduced.  I think it should be possible without any dependencies outside the JVM.  Which are the pluggable pieces?  Do we use our own interfaces or can javax.concurrent classes/interfaces serve that purpose?  Or a mix?

* For each app server, which interface will be given different implementation?  which dependencies will be introduced in those environments?

[ronald_van_kuij]

* Standalone usage: which dependencies will be introduced.  I think it should be possible without any dependencies outside the JVM.

Correct, none

Which are the pluggable pieces?  Do we use our own interfaces or can javax.concurrent classes/interfaces serve that purpose?  Or a mix?

A queue is configured by injecting the correct implementation of a factory. The implementation for standalone requires you to configure min/max pools size and a queuesize.  This factory implements a new interface, the JobWorker.

* For each app server, which interface will be given different implementation?  which dependencies will be introduced in those environments?

There weill be 3 implementations also implementing the JobWorker interface that can be injected in the config, depending on the environment..
- JBoss
- GlassFish
- One for CommonJ compatible servers

This is kind of how Spring does it but way less generic and therefor no dependency on any Spring jar is needed. Since JBoss and GlassFish implement a generic javax.resources interface, lookups and instantiations can all be done via reflection (thanks to spring for the idea) and no new dependency is introduced here. For WLS and Websphere, CommonJ is needed. So in the end only one new dependency is introduced for their interface. I've not checked what repo it is in, but we might 'include' in the code if neeeded. Still have to look at the WebSphere CE/Geronimo what they implement.

[heymjo]

Hi,

Is there any news or planned activities on this ?

Thanks
Jorg

[ronald_van_kuij]

Yes, I'm still currently spliting all my code (multiple issues in one branch) so I can more easliy show them to the rest. This is unfortunately not going realy fast due to a lack of time.

[bardioc]

Hello, I've come to this thread, as I faced an issue with not being able to lookup entries from the Initial Context on WebSphere once a timer fired. This splits the implementation of our process model into two parts:

1. Everything BEFORE a waiting task, such as a timer runs within a thread built by the WebSphere Container
2. Everything AFTER a waiting task, such as a timer runs within a thread created by the JobExecutor.

While 1) allows me to use InitialContext.doLookup("java:comp/env/myDataSource"), 2) will not allow this in WebSphere leading to the following error message:

A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names

From my knowlege in implementing something like what is currently achieved with ACT-34 for Quartz utilizing the WebSphere Workmanager, when using this very API, the JNDI context stays and can be used.

However, I've not seen any news about this. Are you Ronald or somebody else still working on this? Do you need some help regarding tests for WebSphere Integration. I'd be glad to join in, cause this really bugs us right now in moving towards Activiti abandoning jBPM 4.

Thank you very much.

Heiko

PS: I've checked out your branch in the SVN, trying to read myself into it.