I appear to have resolved this issue by changing dialect to MVEL and setting drools.permgenThreshold=0 in META-INF/drools.rulebase.conf. I only stumbled upon this based on some hints in another post and when it didn't work I had to debug the point at which the classes got created and worked back that the permgen threshold was only used by mvel dialect rules. Appalling documentation from a performance and system configuration perspective. -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Perm-gen-grows-constantly-tp4026... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thanks for clearing this up. The overhead for us is negligible and more important that the application is survivable. Using Java as the dialect would appear to not be a option for anyone then? We are using drools to process around 50Mil transactions against 15k rules. This is distributed over 32 nodes to get the end to end performance we need. Using java dialect on initial run with a mac perm size of 512Mb copes ok but on subsequent runs we run out of perm gen space and the processes take up tons of cpu and then run out of memory. For each run we have to recreate the knowledge base. -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Perm-gen-grows-constantly-tp4026... Sent from the Drools: User forum mailing list archive at Nabble.com.

Are you saying the permgen is leaking? That you update the rules, and no perigean space is reclaimed? There are some issues with the JVM, that I’ve seen before, which may be the problem. Such as the CMSClassUnloadingEnabled issue: http://java.dzone.com/articles/busting-permgen-myths I’d be interested to know if this is a pergmen leak, and if it continues on 6.x. If it does, maybe you could work with us to find out why it’s not being reclaimed? Mark On 18 Nov 2013, at 16:56, pmander <paul.s.mander(a)gmail.com&gt; wrote:

We had this issue where the permgen space was not reclaimed as CMS does not by default reclaim unless you use CMSClassUnloadingEnabled . After that we have not seen this though the permgen space keeps growing with addition of rules.The only thing we are afraid that if the permgen space requirement becomes same/greater than the threshold that CMS reclaims then what will happen?.We keep changing/increasing the permgen space but there is a limit to this at some point we can't allocate more proportion of memory for permgen space only ... Thanks & Regards, Adarsh SENIOR LEAD DEVELOPMENT SPECIALIST SCJP, SCWCD FINANCE TECHNOLOGY HSBC BANK PLC HBEU 8 Canada Square,Canary Wharf, London,E14 5HQ,United Kingdom ------------------------------------------------------ Phone +44 207914720 Mobile 07595530105 Email. adarsh.chaini(a)hsbcib.com ________________________________ From: Mark Proctor <mproctor(a)codehaus.org&gt; To: Rules Users List <rules-users(a)lists.jboss.org&gt; Date: 18/11/2013 17:12 Subject: Re: [rules-users] Drools Perm gen grows constantly Sent by: rules-users-bounces(a)lists.jboss.org Are you saying the permgen is leaking? That you update the rules, and no perigean space is reclaimed? There are some issues with the JVM, that I?ve seen before, which may be the problem. Such as the CMSClassUnloadingEnabled issue: http://java.dzone.com/articles/busting-permgen-myths I?d be interested to know if this is a pergmen leak, and if it continues on 6.x. If it does, maybe you could work with us to find out why it?s not being reclaimed? Mark On 18 Nov 2013, at 16:56, pmander <paul.s.mander(a)gmail.com&gt; wrote: rules. need. but up the http://drools.46999.n3.nabble.com/Drools-Perm-gen-grows-constantly-tp4026... _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ************************************************************ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority ************************************************************ ----------------------------------------- SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy.