3 Replies Latest reply on Jun 18, 2012 4:43 AM by Maciej Swiderski

    Scalable use of Timer Events

    Richard Evans Newbie

      Hello there,


      JBPM 5.1.0 running on Tomcat.


      I have a number of processes that invoke async APIs and need to poll for results. I use Timer Events to trigger these checks.The processes all function correctly but I am having problems scaling.


      I have a thread pool for starting the processes with kSession.startProcess(); all threads share a StatefulKnowledgeSession.

      Processes kick off fine and execute any synchronous tasks. As soon as they hit the timer startProcess returns.

      When the timer fires and the process resumes, every process instance seems to be executing in a single timer thread.


      This is heavily throttling throughput and I am ending up with hundreds of in-flight processes trickling through very slowly.


      Can I run multiple threads for the timer? I am very happy for a single process instance to be single-threaded but I really want separate processes to run in parallel both before and after the timer.


      Any hints? Can I kick off multiple threads for the timer? Would it make a difference if I had multiple sessions?

      Many thanks,


        • 1. Re: Scalable use of Timer Events
          Maciej Swiderski Master

          Be default timer service is created with thread pool of size one so that is why you observe this behavior. There are two things you could do:

          1. use separate session as timer service is per session

          2. increase number of threads in the pool by registering timer service on your own


          If you go for option two, here are some hints:

          - if using persistence then make use of JpaJDKTimerService

          - if not use JDKTimerService


          both have constructors that accepts integer that will be used as size of the pool.


          To set this you should use session configuration and set class name for property drools.timerService. As you can see it requires class name and not the instance itself so there is no easy way to set the desired pool size as that uses default constructor. One way to go is to simply extend one of the timer service implementation and make sure that your custom class default constructor will set the pool size to higher value.



          • 2. Re: Scalable use of Timer Events
            Richard Evans Newbie

            Hello Maciej,

            I very much appreciate your reply. Very useful indeed. I have followed option 2 and it seems to be working. A couple of hiccups on the way:


            1. I set drools.timerService in drools.session.conf and it was initially ignored. I was using V5.1 and configuring ksession in spring config with the drools namespace. There did not seem to be any way to configure directly through the drools namespace.


            2. I upgraded to 5.3 and the setting was respected. However I had to change persistence.xml to get V5.3 to work.


            Did you expect this to work on 5.1? I hope I have no problems with 5.3 but it would be nice to know.



            Thanks again,


            • 3. Re: Scalable use of Timer Events
              Maciej Swiderski Master

              Glad to hear it helped.


              Unfortunately can't say for sure about spring/drools integration - not in my domain of knowledge (yet ).


              I would recommend to stick to 5.3 as it brings a lot more features and bug fixes and it should not cause any side effects. But if it does please let us know here or submit a jira.