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@termmed.com>
This memory leak is giving us a lot of problems... we need to iteratively
test 400,000 items, one session for each. It was working fine with 5.1.1 and
now is failing.
Thanks for the test case, is very simple to reproduce, but I tried running
it with:
<dependency>
<groupId>org.drools</groupId>
<artifactId>knowledge-api</artifactId>
<version>5.3.0.CR1</version>
</dependency>
... etc.
And still fails, so I don't fully trust that this will be fixed on 5.3.0...
do you have confirmation?
I need to decide if I wait for 5.3 or if I advice to roll back to 5.1.1.
Thanks
Alejandro
--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-Memory-leak-in-5-2-5-3-tp3280351p3391578.html
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com