I'm using Drools 5.5 in a web application, upgraded a few months ago from 5.1. When starting multiple instances of the application on a server *at the same time*, I recently noticed some problems with the JVMs complaining of not being able to create native threads.

The stack trace led to Drools, and more specifically MvelConstraint submitting JIT tasks to an Executor through its jitEvaluator() method. The Executor is created by ExecutorProviderImpl and is a basic CachedThreadPool, which means it can create an unbounded number of threads (which then die after idling for a minute). In my case, it apparently meant around 900 threads per JVM, which multiplied by the number of running JVMs saturated the OS for a short while.

Has anyone else been bitten by this? Should there be a more reasonable default implementation and should I create an issue for this?

I then have a question related to how I fixed this: I created my own implementation of ExecutorProvider by extending ExecutorProviderImpl and creating a ThreadPoolExecutor with an upper bound on the number of threads and a LinkedBlockingQueue to queue the tasks when all the threads are already busy. That works fine, the only problem is telling Drools to use my implementation: the only way I've found is by calling ServiceRegistryImpl.getInstance().registerLocator(). ServiceRegistryImpl implements ServiceRegistry, but the interface doesn't seem to be exposed through Drools' more public API; it seems a bit wrong to call the implementing class directly to get its instance, especially given the Javadoc which states "This is an internal class, not for public consumption". Am I missing something?

Regards,

Frank