[estaub]

See (lengthy) update on http://jira.jboss.com/jira/browse/JBPM-983

-Ed Staub

[ax666]

thanks ed for working on this problem. I'd like to see some of the developers to work on this too to have it fixed in a public version. we did some bad hacks similar to ed's to get this to work, but still, I believe its not production ready.
right now I don't have any more time to work on this, I just hope our stuff will do... al

[kukeltje]

Alex,

There are 3 ways to get this fixed quickly:
- Develop a good patch and contribute it
- Get many people to vote for the issue
- Buy commercial support and report it as a major issue.

There are currently to few people having a problem with this to get it 'fixed' by the core developers working on it and dropping other things.

[ax666]

Ronald, you're absolutely right, but there's nothing I can do now.
Our hacks are not of a quality for a patch. I can quickly describe what we did:
- new job executor who is starting 1 job reader thread
- job reader thread uses java executor service for thread pool
- reads jobs from db and starts new single job execution thread for each job
- synchronize on "exclusive" and on process id/node
- wait 1 second in each single job execution thread to not interfere with other jobs still running, this is the worst part, but it works
- changes are extensions, no patches. new job executor configured in jbpm config

too bad above doesn't work with 3.2.1

how many is "many people" ?

alex

[kukeltje]

"ax666" wrote:
Ronald, you're absolutely right, but there's nothing I can do now.
Our hacks are not of a quality for a patch. I can quickly describe what we did:
- new job executor who is starting 1 job reader thread
- job reader thread uses java executor service for thread pool
- reads jobs from db and starts new single job execution thread for each job
- synchronize on "exclusive" and on process id/node
- wait 1 second in each single job execution thread to not interfere with other jobs still running, this is the worst part, but it works
- changes are extensions, no patches. new job executor configured in jbpm config

I asked one of the core developers to comment on this, so let's wait on that. Mind that real-time processing was never one of the main requirements of jBPM, so the 1 second is not to bad imo (jms could do this automatically for you with the retry-timeout)

"ax666" wrote:

too bad above doesn't work with 3.2.1

Hmm... so you mean there is a difference in this area between 3.2 and 3.2.1?

"ax666" wrote:

how many is "many people" ?

A few hundred.... no just kidding... getting it in the top 10 of most voted issues should be enough.. 3-5 votes i think

[ax666]

with 3.2.1 :

11:19:01,985 [pool-1-thread-1] DEBUG GraphElement - event 'node-leave' on 'Node(fileCheck)' for 'Token(/)'
11:19:02,003 [pool-1-thread-1] DEBUG GraphElement - event 'transition' on 'Transition(check-to-fork)' for 'Token(/)'
11:19:02,006 [pool-1-thread-1] DEBUG GraphElement - event 'node-enter' on 'Fork(fork1)' for 'Token(/)'
11:19:02,010 [pool-1-thread-1] DEBUG DbMessageService - saved job[2, org.jbpm.job.ExecuteNodeJob]
11:19:02,012 [pool-1-thread-1] DEBUG Token - token[1] is unlocked by token[1]
11:19:02,024 [pool-1-thread-1] ERROR GraphElement - action threw exception: token '1' can't be locked by 'job[2]' cause it's already locked by 'token[1]'
org.jbpm.JbpmException: token '1' can't be locked by 'job[2]' cause it's already locked by 'token[1]'
at org.jbpm.graph.exe.Token.lock(Token.java:646)

[kukeltje]

this occurs with me when I have async on the fork...

[gesha]

"kukeltje" wrote:
....so the 1 second is not to bad imo (jms could do this automatically for you with the retry-timeout)
...

I hope you jocking! ;) I am not agree to loose 99% of performance by getting only 1 command-exec instead of my current 100. 1 sec -solution is only solution for SimpleTest....