JBossDeveloper

ok.. I think Tom will be reluctant to 'fix' this since (and I have to check this) he did not want to build a new highly scalable async system where there is JMS.

If JMS like functionality is required consider using Mule.
I hope this solves your problem

Ronald,

Re JMS... can you explain how you think it will solve these problems? If you mean that there would be only one bean in the pool, that's not solving it at all - that's single-threading all requests.

As I see it, the problem looks like one of token synchronization, and I don't see anything remotely relevant in the JMS support.

-Ed Staub

ok, I partly mixed 2 things up.... but... nevertheless, the one/multiple threads thing of the jobexecutor was never explicitly meant to work (nor was it not meant to work) and no, I was not saying there should be one mdb but maybe the behaviour when jms is involved is different.... and why is it not enough to have multiple timers on one processinstance but have them processed one after the other... prevents locking to. Multiple threads could probably work then.

Still....I think that concurrent access to tokens is another issue... what should the behaviour be in those cases.... rather hard to decide....So is it a theoretical(?) case for workflow? I agree that the second timer should not fail, but rather report something like 'nothing to process anymore' correct?... Someone should try to describe some real scenario's so we can decide what the behaviour should be.

"fady.matar" wrote:
If JMS like functionality is required consider using Mule.
I hope this solves your problem

Alex,

Building these kinds of 'does-this-file-exist' checks is not something we promote in doing with jBPM timers. The better solution is to have an ESB like solution, which often has really good file polling. This can then signal the tokens.

You are correct in the assumption that JMS would not help in this case. I mixed two things up. The thing is that the subject does not cover the issue anymore. The issue is purely related to concurrent access to a token (in this case when 2 tokens go in the join)

Sorry I did not try to run the testcase (yet) Do you get an exeption?

btw, why is there an async=true on the fork? What behaviour do you expect?

If you expect the fork to behave as a multi-threaded parallel execution, then sorry.. that is not what jBPM is/does. If you want that, make the nodes in each leg of a fork async, but not the fork itself.

According to the code, async on a node locks the currenttoken. Not strange then that in the join it cannot be reactivated. So try removing the async on both join and fork.

same ones? if so, can you post a stacktrace? In the meantime I'll try to get the case running

Alex,

I did some tests and I have varying results. Varying in the sense that the same test run multiple times sometimes pass and sometimes don't.

This is what I used for the jobexecuterconfig

<bean name="jbpm.job.executor" class="org.jbpm.job.executor.JobExecutor">
 <field name="jbpmConfiguration"><ref bean="jbpmConfiguration" /></field>
 <field name="name"><string value="JbpmJobExector" /></field>
 <field name="nbrOfThreads"><int value="2" /></field>
 <field name="idleInterval"><int value="5000" /></field>
 <field name="maxIdleInterval"><int value="3600000" /></field> <!-- 1 hour -->
 <field name="historyMaxSize"><int value="20" /></field>
 <field name="maxLockTime"><int value="600000" /></field> <!-- 10 minutes -->
 <field name="lockMonitorInterval"><int value="60000" /></field> <!-- 1 minute -->
 <field name="lockBufferTime"><int value="5000" /></field> <!-- 5 seconds -->
 </bean>

<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="simpletest" >
 <start-state name="start-state1">
 <description>start of the process</description>
 <event type="node-enter">
 <script name="script_start">
 System.out.println("START");
 executionContext.leaveNode();
 </script>
 </event>
 <transition name="start-to-check" to="fileCheck" />
 </start-state>

 <node name="fileCheck">
 <script name="script_filecheck">
 System.out.println("FILE-CHECK");
 executionContext.leaveNode();
 </script>
 <transition name="check-to-fork" to="fork1"></transition>
 </node>

 <fork name="fork1">
 <transition name="toNode1" to="node1"></transition>
 <transition name="toNode2" to="node2"></transition>
 </fork>

 <node name="node1" async="true">
 <script name="script_node1">
 System.out.println("NODE1");
 executionContext.leaveNode();
 </script>
 <transition name="node1toJoin1" to="join1"></transition>
 </node>

 <node name="node2" async="true">
 <script name="script_node2">
 System.out.println("NODE2");
 executionContext.leaveNode();
 </script>
 <transition name="node2toJoin1" to="join1"></transition>
 </node>

 <join name="join1">
 <transition name="join1ToNode3" to="node3"></transition>
 </join>

 <node name="node3">
 <script name="script_node3">
 System.out.println("NODE3");
 </script>
 <transition name="node3ToEnd" to="end-state-success"></transition>
 </node>

 <end-state name="end-state-success">
 <description>process finished normally</description>
 <event type="node-enter">
 <script name="script_endSuccess">
 System.out.println("END-SUCCESS");
 </script>
 </event>
 </end-state>
</process-definition>

public class AlexTest extends AbstractDbTestCase {

 public void testAlex(){

 try {
 ProcessDefinition processDefinition = ProcessDefinition.parseXmlResource("alex.xml");

 processDefinition = saveAndReload(processDefinition);
 ProcessInstance processInstance = new ProcessInstance(processDefinition);
 processInstance.signal();
 jbpmContext.save(processInstance);
 processJobs(20000);
 processDefinition = graphSession.loadProcessDefinition(processDefinition.getId());
 processInstance = graphSession.loadProcessInstance(processInstance.getId());
 assertEquals(processDefinition.getNode("node3"), processInstance.getRootToken().getNode());
 } catch (Exception e) {
 e.printStackTrace();
 assertFalse(true);
 }
 }

}

no, correct, no subprocesses. I used the xml example in this topic