Fix threadpool size for ExecutorProvider
by boukadam
Hi all,
I'm using drools (version 5.5.0) for heavy processes and after many
executions I noticed an important number of Thread instanciated inside the
JVM. After debugging, these threads are created by
org.drools.concurrent.ExecutorProviderImpl. This class provides an executor
service without limitation of pool size :
private static final java.util.concurrent.ExecutorService executor =
Executors.newCachedThreadPool(new ThreadFactory() {
public Thread newThread(Runnable r) {
…
[View More] Thread t = new Thread(r);
t.setDaemon(true);
return t;
}
});;
This implementation is registered for the service in
org.drools.util.ServiceRegistryImpl:
private void init() {
...
addDefault( ExecutorProvider.class,
"org.drools.concurrent.ExecutorProviderImpl");
...
}
Is there a reason to unlimit pool size? This service could be disabled or
overload by another implementation to avoid hundreds of threads inside the
JVM?
Thanks in advance.
Mohammed BOUKADA
--
View this message in context: http://drools.46999.n3.nabble.com/Fix-threadpool-size-for-ExecutorProvide...
Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.
[View Less]
10 years, 9 months
ClassLoader leak in 6.0.1 Final
by A. Craig West
I am currently converting a Drools 5.5.0 installation to 6.0.1 Final,
due to many memory leaks in 5.5.0. Our use case involves a
knowledgebase of several thousand rules which are updated at run-time
quite frequently. As a result, we have found it necessary to do
incremental builds of rules. I based the code for this on the
integration tests:
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test...
This is working fairly well so far, but while testing, I noticed a
fairly …
[View More]severe increase in PermGen heap usage every time I modify my
rules.
Using jhat and the Eclipse memory analyzer, I was able to track down
the source of the problem to a classloader leak in the JavaDialect
class. Whenever a rule is added to the JavaDialect, a RuleErrorHandler
is added to an internal Map named errorHandlers. Unfortunately, this
RuleErrorHandler is never removed, and it contains a reference to a
stale PackageClassLoader. I am still working out how to fix this.
[View Less]
10 years, 10 months