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

[Edson Tirelli]

Frank,

Can I ask you please to open a ticket for this? Feel free to submit a
pull request if you have a solution already, or we will do it
ourselves. I think we should set a reasonable limit for the thread
pool size and optionally allow the user to configure it.

Thanks,
Edson

On Mon, Apr 28, 2014 at 9:49 AM, Frank Pavageau
<frank.pavageau at gmail.com> wrote:
> 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
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users



-- 
  Edson Tirelli
  Principal Software Engineer
  Red Hat Business Systems and Intelligence Group