[JBoss jBPM] - Re: Solution: JBPM3 and Spring Integration
by mr_magoo
The problem to point out is the job executor thread. The overrided example given does not synchronise the acquire jobs properly. This means that there will be a race condition in the acquire jobs thread between the acquireJobs synchronized block in JobExecutorThread and the unsynched one in SpringExecutorThread.
The correct implementation is:
public class SpringExecutorThread extends JobExecutorThread {
|
| private TransactionTemplate transactionTemplate;
| private JobExecutor jobExecutor;
|
| public GfgSpringExecutorThread(
| String name,
| JobExecutor jobExecutor,
| JbpmConfiguration jbpmConfiguration,
| TransactionTemplate transactionTemplate,
| int idleInterval,
| int maxIdleInterval,
| long maxLockTime,
| int maxHistory
| ) {
| super(name, jobExecutor, jbpmConfiguration, idleInterval, maxIdleInterval, maxLockTime, maxHistory);
| this.transactionTemplate = transactionTemplate;
| this.jobExecutor=jobExecutor;
| }
| @Override
| protected Collection acquireJobs() {
| synchronized(jobExecutor) {
| return (Collection) transactionTemplate.execute(new TransactionCallback() {
| public Object doInTransaction(TransactionStatus transactionStatus) {
| return GfgSpringExecutorThread.super.acquireJobs();
| }
| });
| }
| }
| @Override
| protected void executeJob(final Job job) {
| transactionTemplate.execute(new TransactionCallback() {
| public Object doInTransaction(TransactionStatus transactionStatus) {
| GfgSpringExecutorThread.super.executeJob(job);
| return null;
| }
| });
| }
| @Override
| protected Date getNextDueDate() {
| return (Date) transactionTemplate.execute(new TransactionCallback() {
| public Object doInTransaction(TransactionStatus transactionStatus) {
| return GfgSpringExecutorThread.super.getNextDueDate();
| }
| });
| }
| }
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250509#4250509
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250509
16 years, 10 months
[JBoss jBPM] - Solution: JBPM3 and Spring Integration
by mr_magoo
I thought I would pass on some of the hard one lessons here to help people avoid some of the pain I have had to go through. While I think my scenario is perhaps not one that jbpm has in mind specifically, I fear that it is quite a typical scenario in the wild.
Also I think someone else might have a suggestion or ten. I am not claiming to be a jbpm guru.
Required Reading:
http://www.jorambarrez.be/blog/2009/04/17/integrating-jbpm3-with-spring-p...
http://www.jorambarrez.be/blog/2008/08/26/jbpm-job-executor-for-spring/
Problem
JBPM3 architecture assumes and relies heavily on an xml configuration file and dependencies are spread throughout several classes. (sometimes in surprising places and ways)
Penetration of this is rather difficult and a few versions ago nearly impossible due to private/final members/methods in key classes. This was most evident in the job executor and scheduler.
Previously spring-modules was sufficient to integrate with spring, although quite clunky due to the above restrictions. Current wisdom suggests that using the latest version of jbpm with spring-modules can introduce subtle bugs and it appears that the jbpm part of spring modules is now dead.
The reference links above outline an alternative solution but it is somewhat flawed unfortunately when it comes to async processing. It also does not go into specifics on the spring config side of things and how to remove the dependency on the jbpm configuration xml file and have a fully spring injected environment.
I will assume that you have read the references above and have downloaded the source code they reference.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250508#4250508
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250508
16 years, 10 months
[JBoss jBPM] - Re: Problems with indexes in jbpm.history.hbm.xml
by hwa
"hwa" wrote : "kukeltje" wrote : uhhhhhmmmmmm..... you use the class that is your 'test app' also as the actionhandler.... and you do a lot of work in the constructor. Now that is an obvious explanation why you see the loop. since each time your actionhandler is called it is constructed and starts a new process etc... so it is not a loop, but a recursive thing.
| |
| | Separate your java actionhandler from the test class or make the actionhandler an inner class.
|
| Oh shoot. That's a good point. I think I was so busy trying out all the jBPM stuff that I forgot that I had the action handler my test class constructor--I should've seen that already--of course it's looping b/c the constructor was restarting the schema over and over again...dangit...okay, that seemed to solve my problem. Thanks so much!
On a side note, I didn't realize that the action handler would be called until I reached that point in the process. Why would it get called over and over again before the process even starts?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250505#4250505
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250505
16 years, 10 months
[JBoss jBPM] - Re: Problems with indexes in jbpm.history.hbm.xml
by hwa
"kukeltje" wrote : uhhhhhmmmmmm..... you use the class that is your 'test app' also as the actionhandler.... and you do a lot of work in the constructor. Now that is an obvious explanation why you see the loop. since each time your actionhandler is called it is constructed and starts a new process etc... so it is not a loop, but a recursive thing.
|
| Separate your java actionhandler from the test class or make the actionhandler an inner class.
Oh shoot. That's a good point. I think I was so busy trying out all the jBPM stuff that I forgot that I had the action handler my test class constructor--I should've seen that already--of course it's looping b/c the constructor was restarting the schema over and over again...dangit...okay, that seemed to solve my problem. Thanks so much!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250504#4250504
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250504
16 years, 10 months
[JBoss jBPM] - Solution: Large numbers of jobs in JOB table causes major sl
by mr_magoo
Environment:
Oracle with jbpm3, db message queue and async processing.
Problem:
During high volume processing (such as our overnight soak test) the job queue can fill up.
The job executor synchronises the code in the method "acquireJobs" which in turn executes the query:
| select job from org.jbpm.job.Job as job
| where ( (job.lockOwner is null) or (job.lockOwner = :lockOwner) )
| and job.retries > 0
| and job.dueDate <= :now
| and job.processInstance = :processInstance
| and job.isExclusive = true
| and job.isSuspended != true
| order by job.dueDate asc
|
Unfortunately duedate is not indexed and job.dueDate <= :now appears to insure that oracle will fail to optimise the query as ":now" constantly changes. (obviously query plan culls jobs first, then sorts)
Because this is all synchronised it slows the executor pool down and thus more jobs pool and the whole thing begins to crawl. Someone here decribed it as "degrade disgracefully" which is now my personal life long goal as well.
Solution:
Index duedate:
create index IDX_JOB_DUEDATE on JBPM_JOB (DUEDATE_);
Otherwise your DB will be constantly resorting that table.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250501#4250501
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250501
16 years, 10 months