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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users