From acraigwest at gmail.com  Mon Jun  9 17:42:40 2014
From: acraigwest at gmail.com (A. Craig West)
Date: Mon, 9 Jun 2014 17:42:40 -0400
Subject: [rules-dev] ClassLoader leak in 6.0.1 Final
Message-ID: <CAFbfRkrBKyK0c9b-O12HYBafadrVjgf79PrxPjC5fjXD7sa7kw@mail.gmail.com>

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/java/org/drools/compiler/integrationtests/IncrementalCompilationTest.java

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.

From acraigwest at gmail.com  Mon Jun  9 22:39:18 2014
From: acraigwest at gmail.com (A. Craig West)
Date: Mon, 9 Jun 2014 22:39:18 -0400
Subject: [rules-dev] ClassLoader leak in 6.0.1 Final
In-Reply-To: <CAFbfRkrBKyK0c9b-O12HYBafadrVjgf79PrxPjC5fjXD7sa7kw@mail.gmail.com>
References: <CAFbfRkrBKyK0c9b-O12HYBafadrVjgf79PrxPjC5fjXD7sa7kw@mail.gmail.com>
Message-ID: <CAFbfRkpeFQQd24dZstMesTrp=pA+7yn5AMYm3tX+Bpkv0+HBDA@mail.gmail.com>

I found a fix for the ClassLoader leak, and submitted a Jira ticket
with a git pull request. So far it is working quite well...
https://issues.jboss.org/browse/DROOLS-521

On Mon, Jun 9, 2014 at 5:42 PM, A. Craig West <acraigwest at gmail.com> wrote:
> 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/java/org/drools/compiler/integrationtests/IncrementalCompilationTest.java
>
> 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.

From ed.tirelli at gmail.com  Wed Jun 11 10:32:44 2014
From: ed.tirelli at gmail.com (Edson Tirelli)
Date: Wed, 11 Jun 2014 10:32:44 -0400
Subject: [rules-dev] ClassLoader leak in 6.0.1 Final
In-Reply-To: <CAFbfRkpeFQQd24dZstMesTrp=pA+7yn5AMYm3tX+Bpkv0+HBDA@mail.gmail.com>
References: <CAFbfRkrBKyK0c9b-O12HYBafadrVjgf79PrxPjC5fjXD7sa7kw@mail.gmail.com>
	<CAFbfRkpeFQQd24dZstMesTrp=pA+7yn5AMYm3tX+Bpkv0+HBDA@mail.gmail.com>
Message-ID: <CAD7AJnf0SborSxPWJ=u1pyhGvMdLajj2jzVSkNKgtWxTAKa09g@mail.gmail.com>

   Thanks,

   We will check and apply!

    Edson

On Mon, Jun 9, 2014 at 10:39 PM, A. Craig West <acraigwest at gmail.com> wrote:
> I found a fix for the ClassLoader leak, and submitted a Jira ticket
> with a git pull request. So far it is working quite well...
> https://issues.jboss.org/browse/DROOLS-521
>
> On Mon, Jun 9, 2014 at 5:42 PM, A. Craig West <acraigwest at gmail.com> wrote:
>> 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/java/org/drools/compiler/integrationtests/IncrementalCompilationTest.java
>>
>> 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.
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev



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

From index at live.fr  Fri Jun 20 11:40:29 2014
From: index at live.fr (boukadam)
Date: Fri, 20 Jun 2014 08:40:29 -0700 (PDT)
Subject: [rules-dev] Fix threadpool size for ExecutorProvider
Message-ID: <1403278829026-4030123.post@n3.nabble.com>

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-ExecutorProvider-tp4030123.html
Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.

From ventilo35 at free.fr  Wed Jun 25 08:19:23 2014
From: ventilo35 at free.fr (ventilo35)
Date: Wed, 25 Jun 2014 05:19:23 -0700 (PDT)
Subject: [rules-dev] Drools 6 : Dynamic Rules
In-Reply-To: <1390435441987-4027814.post@n3.nabble.com>
References: <1385641359674-4026976.post@n3.nabble.com>
	<9A366BCE-A755-4A7D-A7FC-4E6630694F3C@codehaus.org>
	<1385650612508-4026990.post@n3.nabble.com>
	<80ED66FB-7D2C-43F6-9604-B727C29A8B9F@codehaus.org>
	<CAD7AJnfCmVM9NWS=eTT6eWSSDE7RpWRv-OJN3L6CMvxPqmnFZQ@mail.gmail.com>
	<1390435441987-4027814.post@n3.nabble.com>
Message-ID: <1403698763432-4030152.post@n3.nabble.com>

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-tp4026976p4030152.html
Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.

From mproctor at codehaus.org  Thu Jun 26 12:41:04 2014
From: mproctor at codehaus.org (Mark Proctor)
Date: Thu, 26 Jun 2014 17:41:04 +0100
Subject: [rules-dev] Drools 6 : Dynamic Rules
In-Reply-To: <1403698763432-4030152.post@n3.nabble.com>
References: <1385641359674-4026976.post@n3.nabble.com>
	<9A366BCE-A755-4A7D-A7FC-4E6630694F3C@codehaus.org>
	<1385650612508-4026990.post@n3.nabble.com>
	<80ED66FB-7D2C-43F6-9604-B727C29A8B9F@codehaus.org>
	<CAD7AJnfCmVM9NWS=eTT6eWSSDE7RpWRv-OJN3L6CMvxPqmnFZQ@mail.gmail.com>
	<1390435441987-4027814.post@n3.nabble.com>
	<1403698763432-4030152.post@n3.nabble.com>
Message-ID: <67F655A5-155F-4100-8C84-0E689196D47E@codehaus.org>

These are user questions, please ask them on the user mailing list.

Mark
On 25 Jun 2014, at 13:19, ventilo35 <ventilo35 at free.fr> wrote:

> 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-tp4026976p4030152.html
> Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev