[rules-users] Drools spawning a lot of JIT threads

[Frank Pavageau]

Hi.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140428/da7ca8c6/attachment.html