<div dir="ltr">Hi.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Has anyone else been bitten by this? Should there be a more reasonable default implementation and should I create an issue for this?</div><div><br></div><div>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?</div>
<div><br></div><div>Regards,</div><div>Frank</div></div>