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>
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-tp32...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com