Bug 778868 (SOA-1310)

Alejandro has provided the following input on the support case:

I have some remarks on the attached jBPM configuration:

1. Objects described in any external configuration file *override* objects of the same name in the default configuration provided with the product. The default configuration resource is located in org/jbpm/default.jbpm.cfg.xml within jbpm-jpdl.jar.

2. Objects not overridden in the external file keep the default value. Hence, if you do not need to change an object, avoid setting it explicitly, to allow for the defaults to change in future versions.

3. Do not set nbrOfThreads to 0. Instead, make the jbpm.job.executor object null, as follows:

<null name="jbpm.job.executor" />

This will prevent JobExecutor from being instantiated altogether.

4. All in all, your 'enterprise' configuration should strive to be as close to the settings used in the enterprise module. These settings are under continuous integration, and tested to work.

http://anonsvn.jboss.org/repos/jbpm/jbpm3/branches/jbpm-3.2.5.SP/modules/enterprise/src/main/etc/jbpm.cfg.xml

re: 3. Do not set nbrOfThreads to 0. Instead, make the jbpm.job.executor object null, as follows: 

This results in a NullPointerException with the current ESB->jBPM integration at
        jbpmConfiguration.getJobExecutor().start() ;

in http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/platform/soa_tags/SOA-4.3.0.GA_CP1_CR7/product/services/jbpm/src/main/java/org/jboss/soa/esb/services/jbpm/configuration/JbpmService.java

this is potentially a pandora's box.  a customer is asking for something that we envisioned in the project, but for which we are not comfortable with the level of QA/maturity.

so just running the test suite with this configuration definitely does not give sufficient coverage.

so we risk that the test succeeds, we say to the client to go ahead with this and then the client potentially bumps into one problem after the other.  potential resource sink for us and a bad reputation.

that is why i think we should not go that path.   even if we have to disappoint one customer.

Link: Added: This issue is a dependency of SOA-1328

Link: Added: This issue is a dependency of SOA-1338

Affects: Added: [Documentation (Ref Guide, User Guide, etc.)]

Martin do, you need anything else to set up the QE

Is it possible to port the JBPM-2094 test case, so that the customer will be assured their use case works as intended with the new message/scheduler service implementations.

Link: Added: This issue is related to SOA-1476

This is a public comment to clarify some misconceptions about the work done on this task.

I have to start by stating that this *does not* remove all instances of state state exceptions but only handles one particular area of conflict, specifically the use of multiple job executors over multiple servers/machines.

Using the DB job executor it is likely that there will be concurrent accesses to the *same job* from different machines, causing stale state exceptions to be generated.  This work removes that source of conflict and *no other*.  It is still possible for *different jobs* to modify the same process concurrently.

The original work queries a shared database to retrieve a list of jobs, thereby opening the potential for concurrent executors to execute the same job.  This work replaces the query using a JMS message, whereby the identity of the job to be executed is contained within the message. JMS is then responsible for managing the delivery of the message, thereby guaranteeing that only a single executor will process the job.