Hide Forgot
Affects: Documentation (Ref Guide, User Guide, etc.) Date of First Response: 2009-05-13 09:54:31 Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/288514 project_key: SOA As per customers request, we need to provide an alternative configuration for jBPM which is using the jBPM enterprise components (JMS for async continuations, EJB timers) and add this config to the QA matrix. Setup instructions: ------------------------ 1. Copy jbpm-enterprise.jar to the jbpm.esb directory 2. Modify jbpm.cfg.xml to use JmsMessageServiceFactory and EjbSchedulerServiceFactory (see. JBPM-1952): <!-- <service name="message" factory="org.jbpm.msg.db.DbMessageServiceFactory" /> <service name="scheduler" factory="org.jbpm.scheduler.db.DbSchedulerServiceFactory" /> --> <service name="message"> <factory> <bean class="org.jbpm.msg.jms.JmsMessageServiceFactory"> <field name="connectionFactoryJndiName"> <string value="java:/JmsXA"/> </field> <field name="destinationJndiName"> <string value="queue/JbpmJobQueue"/> </field> </bean> </factory> </service> <service name="scheduler" factory="org.jbpm.scheduler.db.DbSchedulerServiceFactory" /> 3. Modify jbpm.cfg.xml to reduce the number of threads from 1 to 0. <field name="nbrOfThreads"><int value="0" /></field>
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.