did you call ksession.dispose()? Cheers On Wed, Sep 21, 2011 at 1:11 PM, indian9 <viswanath.ivatury(a)chase.com&gt;wrote: -- - CTO @ http://www.plugtree.com - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jugargentina.org - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

I believe early next week, unless something critical arises. Mark Proctor will have the final say. sent on the move On 30 Sep 2011 18:55, "Jamie" <jshaw(a)llbean.com&gt; wrote: Drools so http://drools.46999.n3.nabble.com/rules-users-Memory-leak-in-5-2-5-3-tp32...

I don't know all the details about this problem, but as far as I heard, the leak was happening because jBPM was adding its listener to the kbase and/or ksession and not removing it on disposals... so the easiest way to get around the leak is to simply remove it yourself before disposing the session. Whoever fixed the problem can probably give you details about how to do that. Having said that, if you are using community version, I strongly recommend you to move to 5.3 when it is released as it brings tons of fixes and some good features. Older community versions are not maintained. If you are a Red Hat subscriber, just open a ticket for the version you want to use and they will provide you with patched binaries. Edson 2011/10/3 alopez <alopez(a)termmed.com&gt; -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com

On 04/10/2011 22:51, alopez wrote: That is not safe, and incorrect. __ruleBaseEventListener is the list of rulebase listeners that the current WM adds ot the rulebase. public void addEventListener(RuleBaseEventListener listener) { this.ruleBase.addEventListener( listener ); this.__ruleBaseEventListeners.add( listener ); } When the WM is disposed it should remove it's listeners only. so it iterates __ruleBaseEventListener to find those, and remove them from the rulebase . What you are doing is iterating the rulebase and removing ALL it's listeners, which means it'll remove listeners that belong to other wms. If you are getting a leak like this, it means some how the wm is adding listener, that is not removed - i.e. a listener is not added to __ruleBaseEventListener but is still added to rulebase. If you want this fixed for 5.3, we need a test producing the issue by today. Mark

Hi Marc, Mario, I'm using the same test case on this thread, and oing more tests I now realized what is the problem, this leak appears only if the pom file has the dependency to jbpm-bpmn2 5.1.0.Final along with Drools 5.2.x or 5.3.x. Re-reading Jamie's post earlier I was puzzled by his reference to jbpm-bpmn2 5.1.1.Final, because is not listed as a version on http://www.jboss.org/jbpm, but looking at the public maven repo I saw it really exists, using that version of JBPM resolved the problem, even for 5.2.0.Final. So in summary Drools 5.2.x and forward do not work properly with JBPM 5.1.0.Final, it would probably be helpful to add some reference to this in the release notes. And also maybe provide a link to JBPM 5.1.1.Final that I only saw in the maven repo, no documentation or download link is available in JBPM site. Thanks for your help Alejandro -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Memory-leak-in-5-2-5-3-tp32... Sent from the Drools: User forum mailing list archive at Nabble.com.

Yes, I got the same exception, you can't remove all listeners from the outside (at least in 5.2.0.Final), that's why I patched the AbstractWorkingMemory class to hardcode the listeners removal inside Drools. But now that I found JBPM 5.1.1.Final that seems to solve the problem in a better way, the memory leak doesn't appear in my tests using that version of jbpm in combination with Drools. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Memory-leak-in-5-2-5-3-tp32... Sent from the Drools: User forum mailing list archive at Nabble.com.

On 05/10/2011 19:11, Jamie wrote: you need to be using drools 5.3.CR1 with jbpm 5.1.1.final Mark

as suggested in his post by Thomas , we are retracting the facts from memory. we are doing it in the finally block to make sure a rule session exception does not leave the facts in memory . for ex, we came across an incorrect regular expression syntax within the rules when using incorrect syntax . java.util.regex.PatternSyntaxException: Illegal character range near index 7 ^[A-Za-Z]+ retracting the facts in finally block fixes the leak . That, besides making sure we are reusing the StatefulSession rather than creating a new one every time. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Memory-leak-in-5-2-5-3-tp32... Sent from the Drools: User forum mailing list archive at Nabble.com.