topic Re: Refactor JobExecutor (ACT-34) in Alfresco Archive

Refactor JobExecutor (ACT-34)

ronald_van_kuij — Sun, 16 Jan 2011 18:38:27 GMT

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 integrate

Re: Refactor JobExecutor (ACT-34)

tombaeyens — Mon, 17 Jan 2011 09:28:44 GMT

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?

Re: Refactor JobExecutor (ACT-34)

ronald_van_kuij — Tue, 18 Jan 2011 19:39:01 GMT

* 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.

Re: Refactor JobExecutor (ACT-34)

heymjo — Wed, 25 May 2011 13:41:00 GMT

Hi,

Is there any news or planned activities on this ?

Thanks
Jorg

Re: Refactor JobExecutor (ACT-34)

ronald_van_kuij — Fri, 27 May 2011 06:43:56 GMT

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.

Re: Refactor JobExecutor (ACT-34)

bardioc — Thu, 06 Oct 2011 06:09:12 GMT

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.