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.
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.
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.