1 Reply Latest reply on Jun 21, 2012 3:55 AM by Richard Evans

    Scalability revisited

    Richard Evans Newbie

      JBPM 5.3 running on Tomcat.


      I have a number of processes, each with multiple service tasks making slow external calls. Many are are punctuated by timers to poll for asynch results.


      I am NOT overly bothered about the total time for execution of a single process.

      I AM very bothered about throughput.



      Based on my initial understanding , I had a pool of threads for starting the processes with kSession.startProcess(). They share a single ksession. Lets call these foreground threads.

      I then discovered that events after timers (waits) were being executed by a single thread so, with help from this forum, I increased the number of threads serving these activities. Background threads, I'll call these.


      I expected throughput to be good now but it I find that my foreground threads are doing little parallel work. Threads are frequently blocked. I went a far as to insert 1ms timers at the start of each process in the hope that foreground threads would return quickly and the load be shared across the background threads. Still no luck. I have not yet pinpointed exact behaviour but figured that it was worth a post to see if someone could explain the behaviour and/or tell me how I can increase throughput.


      As well as general advice, some specific questions:

      • Can one KSession only handle support a single thread of execution? Is that where my blocking is arising?
      • Are fast-acting service tasks the ONLY answer? I was hoping to avoid this by the use of threads described above.
      • Does someone have a good example of how to achieve this in a parallel thread? Is it just a question of using the ksession to aquire a fresh workItemManager or is there more to it?


      Your help will be much appreciated!


        • 1. Re: Scalability revisited
          Richard Evans Newbie

          Execution is clearly serialised per session. I will give each thread  its own session and see how I get on. I wonder, now, why I'd want multiple timer threads per session as I guess their execution will be syncronised on any process activities. Am I right?


          If I have a pool of threads, each with a session, I'm hoping throughput will be OK. However I may still want to make service tasks asynchonous in order to commit database activities per task because jbpm will only commit when it hits a wait. Am I correct in assuming that I'll have to use the same session in my asynch thread?