Thanks, I have reproduced the issue using the provided test case.
Indeed there are two relatively independent ways to hit the permgen :
jitted constraints
and rule consequences (when the java dialect is used).
In the test, with the default values a permgen of ~300MB is needed to
accomodate the
15000 rules and their constraints.
The problem is that, for each oneIteration, a brand new Knowledge Base
is rebuilt from scratch,
requiring additional ~300MB of permgen. I guess that this is done to
simulate the multiple
deployments.. disposing the session, obviously, does not dispose the
knowledge base
- there might be other sessions - and at the moment there is no way to
"dispose" a KB:
the classes generated for that KB are referenced indirectly by the main
classloader
(through drools 5.x's composite classloader), which is shared between
the KBs.
I'll make some experiments and see what can be done about it.
Of course, if one can avoid multiple KBs and just work with one KB and
multiple sessions, the
problem is less likely to arise.
Davide
On 12/05/2013 08:58 AM, brachi wrote:
yes because of permgen leak, see previous page...
I must use mvel because only if I use it I don't have permgen.
drools version: 5.4.0.Final also on 5.5.0.Final
--
View this message in context:
http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027115.html
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