did you try an index on the actorId column of JBPM_TASKINSTANCE ?
I've noticed a few operations that are very, very slow. I'm going to bet this is entirely due to the hibernate configuration, which I assume this is because the folks working on this are focusing on bug fixes and feature implementation, and planning optimization for later.
The great thing about hibernate is that making a couple minor changes will probably smooth the whole thing out. I'm going to play around with that for a little bit today.
That's the good news. The bad news is that currently the system is doing some very unefficient things. I turned sql on, and calling 'findTaskInstances' for some reason runs a huge query PER TASK! Check out the join on this baby. Remember, there is one of these PER TASK...
from JBPM_MODULEINSTANCE taskmgmtin0_
left outer join JBPM_PROCESSINSTANCE processins1_ on taskmgmtin0_.PROCESSINSTANCE_=processins1_.ID_
left outer join JBPM_PROCESSDEFINITION processdef2_ on processins1_.PROCESSDEFINITION_=processdef2_.ID_
left outer join JBPM_NODE startstate3_ on processdef2_.STARTSTATE_=startstate3_.ID_
left outer join JBPM_PROCESSDEFINITION processdef4_ on startstate3_.PROCESSDEFINITION_=processdef4_.ID_
left outer join JBPM_ACTION action5_ on startstate3_.ACTION_=action5_.ID_
left outer join JBPM_ACTION action6_ on action5_.REFERENCEDACTION_=action6_.ID_
left outer join JBPM_DELEGATION delegation7_on action6_.ACTIONDELEGATION_=delegation7_.ID_
left outer join JBPM_PROCESSDEFINITION processdef8_ on delegation7_.PROCESSDEFINITION_=processdef8_.ID_
left outer join JBPM_EVENT event9_ on action6_.EVENT_=event9_.ID_
left outer join JBPM_PROCESSDEFINITION processdef10_ on action6_.PROCESSDEFINITION_=processdef10_.ID_
left outer join JBPM_ACTION action11_ on action6_.TIMERACTION_=action11_.ID_
left outer join JBPM_NODE superstate12_ on startstate3_.SUPERSTATE_=superstate12_.ID_
left outer join JBPM_TOKEN token13_ on processins1_.ROOTTOKEN_=token13_.ID_
left outer join JBPM_NODE node14_ on token13_.NODE_=node14_.ID_
left outer join JBPM_PROCESSDEFINITION processdef15_ on node14_.SUBPROCESSDEFINITION_=processdef15_.ID_
left outer join JBPM_DELEGATION delegation16_ on node14_.DECISIONDELEGATION=delegation16_.ID_
left outer join JBPM_PROCESSINSTANCE processins17_ on token13_.PROCESSINSTANCE_=processins17_.ID_
left outer join JBPM_TOKEN token18_ on processins17_.SUPERPROCESSTOKEN_=token18_.ID_
left outer join JBPM_TOKEN token19_ on token18_.PARENT_=token19_.ID_
left outer join JBPM_MODULEDEFINITION taskmgmtde20_ on taskmgmtin0_.TASKMGMTDEFINITION_=taskmgmtde20_.ID_
left outer join JBPM_PROCESSDEFINITION processdef21_ on taskmgmtde20_.PROCESSDEFINITION_=processdef21_.ID_
left outer join JBPM_TASK task22_ on taskmgmtde20_.STARTTASK_=task22_.ID_
left outer join JBPM_PROCESSDEFINITION processdef23_ on task22_.PROCESSDEFINITION_=processdef23_.ID_
left outer join JBPM_MODULEDEFINITION taskmgmtde24_ on task22_.TASKMGMTDEFINITION_=taskmgmtde24_.ID_
left outer join JBPM_NODE tasknode25_ on task22_.TASKNODE_=tasknode25_.ID_
left outer join JBPM_NODE startstate26_ on task22_.STARTSTATE_=startstate26_.ID_
left outer join JBPM_DELEGATION delegation27_ on task22_.ASSIGNMENTDELEGATION_=delegation27_.ID_
left outer join JBPM_SWIMLANE swimlane28_ on task22_.SWIMLANE_=swimlane28_.ID_
left outer join JBPM_DELEGATION delegation29_ on swimlane28_.ASSIGNMENTDELEGATION_=delegation29_.ID_
left outer join JBPM_MODULEDEFINITION taskmgmtde30_ on swimlane28_.TASKMGMTDEFINITION_=taskmgmtde30_.ID_
left outer join JBPM_TASKCONTROLLER taskcontro31_ on task22_.TASKCONTROLLER_=taskcontro31_.ID_
left outer join JBPM_DELEGATION delegation32_on taskcontro31_.TASKCONTROLLERDELEGATION_=delegation32_.ID_
where taskmgmtin0_.ID_=? and taskmgmtin0_.CLASS_='T'
Huge. I have some idea of why this is happening and I'll play with it. Also, setting up the cache in some reasonable manner will probably take care of this.
Again, I think the way the system is set up is good, and you shouldn't worry about the performance that you're seeing right now. It can be MUCH better with minimal config changes. Will the optimized performance be good enough for you? No idea.
Not entirely accurate. It does 2 queries per-task. The one I posted was the second one, this is the first one....
from JBPM_TOKEN token0_
left outer join JBPM_NODE node1_ on token0_.NODE_=node1_.ID_
left outer join JBPM_PROCESSDEFINITION processdef2_ on node1_.PROCESSDEFINITION_=processdef2_.ID_
left outer join JBPM_NODE startstate3_ on processdef2_.STARTSTATE_=startstate3_.ID_
left outer join JBPM_ACTION action4_ on startstate3_.ACTION_=action4_.ID_
left outer join JBPM_ACTION action5_ on action4_.REFERENCEDACTION_=action5_.ID_
left outer join JBPM_DELEGATION delegation6_ on action5_.ACTIONDELEGATION_=delegation6_.ID_
left outer join JBPM_PROCESSDEFINITION processdef7_ on delegation6_.PROCESSDEFINITION_=processdef7_.ID_
left outer join JBPM_EVENT event8_ on action5_.EVENT_=event8_.ID_
left outer join JBPM_PROCESSDEFINITION processdef9_ on action5_.PROCESSDEFINITION_=processdef9_.ID_
left outer join JBPM_ACTION action10_ on action5_.TIMERACTION_=action10_.ID_
left outer join JBPM_NODE superstate11_ on startstate3_.SUPERSTATE_=superstate11_.ID_
left outer join JBPM_PROCESSDEFINITION processdef12_ on node1_.SUBPROCESSDEFINITION_=processdef12_.ID_
left outer join JBPM_DELEGATION delegation13_ on node1_.DECISIONDELEGATION=delegation13_.ID_
left outer join JBPM_PROCESSINSTANCE processins14_ on token0_.PROCESSINSTANCE_=processins14_.ID_
left outer join JBPM_PROCESSDEFINITION processdef15_ on processins14_.PROCESSDEFINITION_=processdef15_.ID_
left outer join JBPM_TOKEN token16_ on processins14_.ROOTTOKEN_=token16_.ID_
left outer join JBPM_TOKEN token17_ on token16_.PARENT_=token17_.ID_
left outer join JBPM_TOKENtoken18_ on processins14_.SUPERPROCESSTOKEN_=token18_.ID_ where token0_.ID_=?
Not sure why, but again, going to play around with it.
Ok. No idea. I set everything in the TaskInstance.hbm.xml file to explicit 'lasy="true"'. Still does the 2 queries per-task thing. I'm absolutely sure there's a way to make it do actual lazy loading, but I'm letting it go for right now. Other stuff to do.
the problem is that you can't put lazy=true on the runtime objects. because of the this pointer problem that arises with the usage of proxies. see this discussion. http://opensource2.atlassian.com/projects/hibernate/browse/HHH-223
one way to resolve this is by making use of precompilation. we plan on doing precompilation with the hibernate instrument ant task. we didn't fully verify that so we have not put it yet in the distribution.
summary: instrument all the jbpm classes with the hibernate instrument ant task. then you can remove all the lazy="false" attributes in the jbpm hibernate mapping files.
that should drastically improve performance.
Interesting. Very interesting. I remember reading one of the big plusses of Hibernate over, say JDO, was that it didn't require byte code manipulation. Not that I care personally.
Good info to know.
I tried adding this to the build file. It processed all the class files. Worked ok till the end, when I got the following:
[my path]\build.xml:54: java.lang.IllegalArgumentException: Field $CGLIB_READ_WRITE_CALLBACK is not declared in org.jbpm.db.jmx.JbpmServiceMBean
And the build script stopped. I look all over the place for CGLIB_READ_WRITE_CALLBACK, including Google and the sources for Hibernate and cglib. Here is the extent of what I've found:
Its used in 'net.sf.cglib.transform.impl.InterceptFieldTransformer'
A chinese pdf that has an example of it being used...
I'm surprised that there is little or nothing on that out there, but for today I'm letting it go.
Ok, didn't quite give up. I took a complete shot in the dark and tossed this...
public void $CGLIB_READ_WRITE_CALLBACK();
right onto the 'JbpmServiceMBean'. I assumed that the compile would fail, or the hibernate task would fail. Neither failed. I have to assume that this is totally wrong. I'm not even sure why I tried it. I have no idea what that method is supposed to do.
I deployed it. It works. It does not appear to do the lazy loading, but it works. I'm going to take it out and rebuild because, again, I'm sure that its wrong.
I'm having the same issue. I wonder if there are any updates on the topic?
When an actor has only 2-3 open tasks the "findTaskInstances" method returns in less then 3 seconds, but with 200 open tasks the response times goes in the 120-150s range. Using jBPM version 3.0.2.
Thanks and regards,