Re: [rules-dev] Drools 6 : Dynamic Rules
by ventilo35
Hi
I would also be very interested in an answer to jhusby's previous question
in this thread
I.e. is it possible to simply rebuild the repository, call
kContainer.updateToVersion(), and have the the session (with all my objects
still populated) automatically use that new version of the rules repository?
Specifically, can the new rules be fired based on the knowledge that was
inserted prior to them being added?
Thanks in advance
Francois
--
View this message in context: http://drools.46999.n3.nabble.com/Drools-6-Dynamic-Rules-tp4026976p403015...
Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.
10 years, 1 month
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) {
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.
10 years, 1 month
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 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.
10 years, 1 month
