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.pavag...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli Principal Software Engineer Red Hat Business Systems and Intelligence Group _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
