Re: [rules-users] permgen leak
Mark, Thanks for your reply. We have been testing against 5.5.0.Final and we faced some problems . One of the problem was that we had a quick fix to mvel component from redhat guys (with their good will )to one of the critical concurrency issues we faced .But it seems that fix is not part of these community releases and there has been changes to mvel after that change. Is there a way that we can make the same permgen fix to the 5.4.0.Final codebase?. Or Is this possible to get the concurrency fix these newer versions?. Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile +44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 15/01/2014 21:05 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org why not just update to 5.6, it?s fixed there. http://downloads.jboss.org/drools/release/5.6.0.Final/ You can specify dialect at the top of the drl file, to be applied to all rules in that file. But that?s about it. Mark On 15 Jan 2014, at 20:51, adarsh.cha...@hsbcib.com wrote: Is this possible to set everything to MVEL Dialect as we are using JavaDialect in all our rules. We had this few times before and we managed to avoid it with usage of CMSClassUnlaoadingEnabled . But this has again comeback recently because the rate at which the classes are produced with load,CMS is unable to collect the permgen space at same rate so it trips Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile +44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 15/01/2014 18:27 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org You can try setting everything to the MVEL dialect, and also forcing MVEL to reflection via the system property (turning off jit) http://mvel.codehaus.org/Disabling+the+JIT+Compiler Mark On 15 Jan 2014, at 18:23, adarsh.cha...@hsbcib.com wrote: Hi Mark/Davide Is there a work around to this problem in 5.4?. Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile +44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 08/01/2014 04:46 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org For anyone interested. The commit involves addressing two needs. 1) Enforcing MVEL reflection mode throughout - MVEL ASM optimiser can NEVER be used for anything (it doesn?t add much value anyway). 2) Avoiding giving the template system the root class loader(which we use for dynamic stuff), as those templates are statically cached. https://github.com/sotty/drools/commit/1b75d4785861e72338cc5ea1280610a7937be017 Mark On 8 Jan 2014, at 00:53, Mark Proctor mproc...@codehaus.org wrote: The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn?t be - we just haven?t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I
Re: [rules-users] permgen leak
On 16 Jan 2014, at 10:09, adarsh.cha...@hsbcib.com wrote: Mark, Thanks for your reply. This is a different discussion than the topic, which is about perm gen leaks. Please start new threads, for new topics. http://www.jboss.org/drools/lists Anti-patterns to be ignored or attract abuse from others: 12. Reply to an existing thread but starting a new topic We have been testing against 5.5.0.Final and we faced some problems . One of the problem was that we had a quick fix to mvel component from redhat guys (with their good will ) If you are a paying customer, best to use the customer portal. Questions are tracked under SLA, and help shape product updates. to one of the critical concurrency issues we faced .But it seems that fix is not part of these community releases and there has been changes to mvel after that change. Is there a way that we can make the same permgen fix to the 5.4.0.Final codebase?. we don’t do maintenance releases in community, i.e. no 5.4.1. Or Is this possible to get the concurrency fix these newer versions?. The fix will be in the next product patch release, check with the customer portal for details. Mark Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile+44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 15/01/2014 21:05 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org why not just update to 5.6, it’s fixed there. http://downloads.jboss.org/drools/release/5.6.0.Final/ You can specify dialect at the top of the drl file, to be applied to all rules in that file. But that’s about it. Mark On 15 Jan 2014, at 20:51, adarsh.cha...@hsbcib.com wrote: Is this possible to set everything to MVEL Dialect as we are using JavaDialect in all our rules. We had this few times before and we managed to avoid it with usage of CMSClassUnlaoadingEnabled . But this has again comeback recently because the rate at which the classes are produced with load,CMS is unable to collect the permgen space at same rate so it trips Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile+44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 15/01/2014 18:27 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org You can try setting everything to the MVEL dialect, and also forcing MVEL to reflection via the system property (turning off jit) http://mvel.codehaus.org/Disabling+the+JIT+Compiler Mark On 15 Jan 2014, at 18:23, adarsh.cha...@hsbcib.com wrote: Hi Mark/Davide Is there a work around to this problem in 5.4?. Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile+44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 08/01/2014 04:46 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org For anyone interested. The commit involves addressing two needs. 1) Enforcing MVEL reflection mode throughout - MVEL ASM optimiser can NEVER be used for anything (it doesn’t add much value anyway). 2) Avoiding giving the template system the root class loader(which we use for dynamic stuff), as those templates are statically cached. https://github.com/sotty/drools/commit/1b75d4785861e72338cc5ea1280610a7937be017 Mark On 8 Jan 2014, at 00:53, Mark Proctor mproc...@codehaus.org wrote: The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach
Re: [rules-users] permgen leak
Hi Mark/Davide Is there a work around to this problem in 5.4?. Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile +44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 08/01/2014 04:46 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org For anyone interested. The commit involves addressing two needs. 1) Enforcing MVEL reflection mode throughout - MVEL ASM optimiser can NEVER be used for anything (it doesn?t add much value anyway). 2) Avoiding giving the template system the root class loader(which we use for dynamic stuff), as those templates are statically cached. https://github.com/sotty/drools/commit/1b75d4785861e72338cc5ea1280610a7937be017 Mark On 8 Jan 2014, at 00:53, Mark Proctor mproc...@codehaus.org wrote: The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn?t be - we just haven?t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I?ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don?t think any core developers will have time to address this. At least not for 5.x; we?ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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 ___ 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 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 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
Re: [rules-users] permgen leak
You can try setting everything to the MVEL dialect, and also forcing MVEL to reflection via the system property (turning off jit) http://mvel.codehaus.org/Disabling+the+JIT+Compiler Mark On 15 Jan 2014, at 18:23, adarsh.cha...@hsbcib.com wrote: Hi Mark/Davide Is there a work around to this problem in 5.4?. Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile+44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 08/01/2014 04:46 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org For anyone interested. The commit involves addressing two needs. 1) Enforcing MVEL reflection mode throughout - MVEL ASM optimiser can NEVER be used for anything (it doesn’t add much value anyway). 2) Avoiding giving the template system the root class loader(which we use for dynamic stuff), as those templates are statically cached. https://github.com/sotty/drools/commit/1b75d4785861e72338cc5ea1280610a7937be017 Mark On 8 Jan 2014, at 00:53, Mark Proctor mproc...@codehaus.org wrote: The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn’t be - we just haven’t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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 ___ 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 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
Re: [rules-users] permgen leak
why not just update to 5.6, it’s fixed there. http://downloads.jboss.org/drools/release/5.6.0.Final/ You can specify dialect at the top of the drl file, to be applied to all rules in that file. But that’s about it. Mark On 15 Jan 2014, at 20:51, adarsh.cha...@hsbcib.com wrote: Is this possible to set everything to MVEL Dialect as we are using JavaDialect in all our rules. We had this few times before and we managed to avoid it with usage of CMSClassUnlaoadingEnabled . But this has again comeback recently because the rate at which the classes are produced with load,CMS is unable to collect the permgen space at same rate so it trips Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile+44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 15/01/2014 18:27 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org You can try setting everything to the MVEL dialect, and also forcing MVEL to reflection via the system property (turning off jit) http://mvel.codehaus.org/Disabling+the+JIT+Compiler Mark On 15 Jan 2014, at 18:23, adarsh.cha...@hsbcib.com wrote: Hi Mark/Davide Is there a work around to this problem in 5.4?. Thanks and regards, Adarsh CHAINI SENIOR LEAD DEVELOPMENT SPECIALIST | HSBC Bank Plc 8 Canada Square, London E14 5HQ, UK ___ Phone Int: (0)79914720 Ext: +44 (0)20 79914720 Mobile+44(0)7595530105 Email adarsh.cha...@hsbcib.com ___ Protect our environment - please only print this if you have to! From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Date: 08/01/2014 04:46 Subject: Re: [rules-users] permgen leak Sent by: rules-users-boun...@lists.jboss.org For anyone interested. The commit involves addressing two needs. 1) Enforcing MVEL reflection mode throughout - MVEL ASM optimiser can NEVER be used for anything (it doesn’t add much value anyway). 2) Avoiding giving the template system the root class loader(which we use for dynamic stuff), as those templates are statically cached. https://github.com/sotty/drools/commit/1b75d4785861e72338cc5ea1280610a7937be017 Mark On 8 Jan 2014, at 00:53, Mark Proctor mproc...@codehaus.org wrote: The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn’t be - we just haven’t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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
Re: [rules-users] permgen leak
Hi, This may be a very basic question, but I'm using drools 5.1.1 and when I invoke a stateful session and that session ends I receive back all of the facts that were created during that session and I translate those into an EDI transaction. As an example I might have a few objects of types 2700*LX,2750* N1,2750* REF, and 2750*DTP. I know my rules fired create objects like: LX*1 N1*75*CMSEC REF*17*A DTP*007*D8*20140114 LX*2 N1*75*STATUS REF*17*AFTNM DTP*007*D8*20140114 Each of these lines is an object of the type I mentioned above. My task is to make sure that the different object types stick together when I put them in the .x12 file so that they are formatted above. What I do internally is I keep track that I have two of each of these objects, but I don't know if there is some type of timestamp that is on them that I could keep the first LX, N1, REF, DTP together or not. In one example I have a rule that inserts them in the order you see, yes, it literally inserts 8 objects/facts into memory. And I need to know the order they were inserted so that I can properly form a file out of them on the backend. Any thoughts? Thanks, Dean ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] permgen leak
Please don’t reply to existing posts, to start new discussions, it screws up the threads. Please read: http://www.jboss.org/drools/lists Anti-patterns to be ignored or attract abuse from others: 12. Reply to an existing thread but starting a new topic Mark On 16 Jan 2014, at 03:40, Dean Whisnant d...@basys.com wrote: Hi, This may be a very basic question, but I'm using drools 5.1.1 and when I invoke a stateful session and that session ends I receive back all of the facts that were created during that session and I translate those into an EDI transaction. As an example I might have a few objects of types 2700*LX,2750* N1,2750* REF, and 2750*DTP. I know my rules fired create objects like: LX*1 N1*75*CMSEC REF*17*A DTP*007*D8*20140114 LX*2 N1*75*STATUS REF*17*AFTNM DTP*007*D8*20140114 Each of these lines is an object of the type I mentioned above. My task is to make sure that the different object types stick together when I put them in the .x12 file so that they are formatted above. What I do internally is I keep track that I have two of each of these objects, but I don't know if there is some type of timestamp that is on them that I could keep the first LX, N1, REF, DTP together or not. In one example I have a rule that inserts them in the order you see, yes, it literally inserts 8 objects/facts into memory. And I need to know the order they were inserted so that I can properly form a file out of them on the backend. Any thoughts? Thanks, Dean ___ 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
Re: [rules-users] permgen leak
The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn’t be - we just haven’t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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 ___ 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
Re: [rules-users] permgen leak
For anyone interested. The commit involves addressing two needs. 1) Enforcing MVEL reflection mode throughout - MVEL ASM optimiser can NEVER be used for anything (it doesn’t add much value anyway). 2) Avoiding giving the template system the root class loader(which we use for dynamic stuff), as those templates are statically cached. https://github.com/sotty/drools/commit/1b75d4785861e72338cc5ea1280610a7937be017 Mark On 8 Jan 2014, at 00:53, Mark Proctor mproc...@codehaus.org wrote: The root of the perm gen leak has now be solved, thanks to some heroic work by community developer Davide Sottara. This is just in time for the 5.6 release going out this week. You will not need to use the kbase.dispose() work around. Mark On 6 Jan 2014, at 20:50, Mark Proctor mproc...@codehaus.org wrote: The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn’t be - we just haven’t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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 ___ 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
Re: [rules-users] permgen leak
1. when will you estimate that 5.6.0.Final will published out? 2. why did you add this dispose methods on the implementation and not on the interface, I don't want to cust the builder and kbase in order to dispose, can it be? 3. It occurs also on 6.0. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027530.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
Re: [rules-users] permgen leak
I have memory leak when using java dialect that doesn't happen with mvel dialect. when change to mvel some rules that hit with java doesn't hit now.and I got compilation errors. this memory leak occurs also at 6.0. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027534.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
Re: [rules-users] permgen leak
see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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
Re: [rules-users] permgen leak
Can you help with any self contained unit tests, to measure, test and prove this? Did you set CMSClassUnloadingEnabled http://stackoverflow.com/questions/3334911/what-does-jvm-flag-cmsclassunloadingenabled-actually-do Mark On 6 Jan 2014, at 14:31, brachi brach...@sapiens.com wrote: I have memory leak when using java dialect that doesn't happen with mvel dialect. when change to mvel some rules that hit with java doesn't hit now.and I got compilation errors. this memory leak occurs also at 6.0. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027534.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
Re: [rules-users] permgen leak
I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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
Re: [rules-users] permgen leak
I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] permgen leak
The 5.6 approach should be considered a work around, not a fix. Somewhere a ref is being held, that shouldn’t be - we just haven’t found it yet. Mark On 6 Jan 2014, at 19:17, Davide Sottara dso...@gmail.com wrote: I have run pmander's tests, and reported in a previous email. The leak in 5.x is due to the nature of the composite classloader, and dispose() forces the memory to be released. I don't remember if that fix was in 5.6.CR1 (probably not), so you may have to try 5.6.0-SNAPSHOT or wait for the end of the week. 6.x does not suffer from the same problem, but has a different issue - no way to unload kie modules once they are cached - which Mario has been working on. In either case, pmander's test works fine in both 5.6.x and 6.x after these fixes Davide On 01/06/2014 07:56 PM, Mark Proctor wrote: I’ve been told 5.6 will be released this week. This is because the JCR2GIT migration tool, in 5.6 is needed for our 6.0 product. Davide's current kbase.dispose() method, on the concrete class, should just be considered a work around for the problem. Unless this is fixed by someone in the community, I don’t think any core developers will have time to address this. At least not for 5.x; we’ll continue to look into it for 6.x. Mark On 6 Jan 2014, at 16:14, brachi brach...@sapiens.com wrote: see previous messages, pmander attached a unit test -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027539.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 ___ 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
Re: [rules-users] permgen leak
Hi, You mention that the brand new kbase evertime could be a problem and you may get this from re-deployments. In my situation I am not in an app server and so do not have a re-deployment issue but I am creating a new kbase every time I run through the system. The system dynamically creates the drl from database definitions and this is done for each run of the application. Is there an alternative for this? -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027321.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
Re: [rules-users] permgen leak
No, there is indeed a very subtle leak.. apparently due to some static references held by MVEL which do not 'work well' with the CompositeClassLoader. I am working on some dispose methods that allow to release the resources and solve the problem (I'll follow up with another email later). They will be available in 5.6.0.Final this week. Version 6.x is not affected instead since it does not rely on the CCL anymore. Davide On 12/16/2013 03:27 AM, pmander wrote: Hi, You mention that the brand new kbase evertime could be a problem and you may get this from re-deployments. In my situation I am not in an app server and so do not have a re-deployment issue but I am creating a new kbase every time I run through the system. The system dynamically creates the drl from database definitions and this is done for each run of the application. Is there an alternative for this? -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027321.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
Re: [rules-users] permgen leak
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
Re: [rules-users] permgen leak
I got a compilation error whith MVEL dialect, on string contains ; character. unterminated string literal any idea? -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027111.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
Re: [rules-users] permgen leak
No crystal ball here: full example, Drools version, please. -W On 05/12/2013, brachi brach...@sapiens.com wrote: I got a compilation error whith MVEL dialect, on string contains ; character. unterminated string literal any idea? -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027111.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
Re: [rules-users] permgen leak
permgen leak? -W On 05/12/2013, brachi brach...@sapiens.com wrote: I got a compilation error whith MVEL dialect, on string contains ; character. unterminated string literal any idea? -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027111.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
Re: [rules-users] permgen leak
I'm putting together a test now. Should be ready in about an hour On Dec 2, 2013, at 11:28 PM, Mark Proctor mproc...@codehaus.org wrote: At this point we are probably stuck, without a unit test that reproduces the issue. Or better still a patch fixing it. Mark On 2 Dec 2013, at 19:41, brachi brach...@sapiens.com wrote: thanks, I used CMSClassUnloadingEnabled, but this can't help because the GC can't garbage this classes because they are in use somewhere, that is actually the leak. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027052.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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] permgen leak
thank you pmander, I tried the dialect mval and the permgen size was 150m after the deployment. still have some compilation and runtime issues because of the dialect... waiting to your unit test, I hope it will help us solve this problem. thank you very much! -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027064.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
Re: [rules-users] permgen leak
permgen.zip http://drools.46999.n3.nabble.com/file/n4027065/permgen.zip Here's the test I was using. You can change the dialect, number of runs, batches, rules etc as attributes in the test class. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027065.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
Re: [rules-users] permgen leak
Oh, and run the test with -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=512m or else it will fail straight away. Paul -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027066.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] permgen leak
i'm using drools 5.5.0, after the rules deployment, (associate DRL's with the KnowladBase and compile them) my permgen grows to 500m, and also if i undeploy, the permgen doesn't cleaned up. (only if i restart the server) It won't help me to increase the permgen size, because the client does a lot of heavy deployment, and can be in the maximum size by 3-4 deployments. I tried this tomcat flags, and it does nothing: -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC I tried set the flag : PermGenThreshold=0, like other people suggested in your forums and it doesn't help. any help? it's production issue... -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038.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
Re: [rules-users] permgen leak
I found that changing dialect to mvel stopped jitting classes and the performance hit was not noticeable. On 2 December 2013 15:51, brachi brach...@sapiens.com wrote: i'm using drools 5.5.0, after the rules deployment, (associate DRL's with the KnowladBase and compile them) my permgen grows to 500m, and also if i undeploy, the permgen doesn't cleaned up. (only if i restart the server) It won't help me to increase the permgen size, because the client does a lot of heavy deployment, and can be in the maximum size by 3-4 deployments. I tried this tomcat flags, and it does nothing: -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC I tried set the flag : PermGenThreshold=0, like other people suggested in your forums and it doesn't help. any help? it's production issue... -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038.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
Re: [rules-users] permgen leak
i tried it. wasn't help. i used MAT to analyze the leak, and it points on mvel2.optimizer -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027040.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
Re: [rules-users] permgen leak
When you say that it won’t help to increase the permgen size, are you saying that you have tried it and it didn’t work? What size does it reach, given an extra gig or 2? How much is it growing for each redeployment? Also from your explanation, it would appear that permgen is hitting 500 meg before you insert any facts into working memory. Is that the case? On 2 Dec 2013, at 16:05, brachi brach...@sapiens.com wrote: i tried it. wasn't help. i used MAT to analyze the leak, and it points on mvel2.optimizer -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027040.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
Re: [rules-users] permgen leak
and set drools.permgenThreshold=0 in drools.rulebase.conf On 2 December 2013 16:05, brachi brach...@sapiens.com wrote: i tried it. wasn't help. i used MAT to analyze the leak, and it points on mvel2.optimizer -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027040.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
Re: [rules-users] permgen leak
i did, nothing changed. the leak still exists. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027045.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
Re: [rules-users] permgen leak
increasing the size solves the out of memory exception. but didn't solve the leak. i can increase it to 2G and i will be able to work, but will fail in the next deployments. this memory won't cleaned up, only if I will restart the server. the leak can't be solve by increasing the memory. and yes, without insert any facts, memory is being 500 mega, after fireAll() it being 650 mega. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027046.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
Re: [rules-users] permgen leak
This is exactly what happened to me. I was getting 500mb of perm gen that would eventually blow the heap when refreshing the rules. I switch to Mvel and changed that setting and now I just have a steady 50m perm gen that doesn't grow On Dec 2, 2013, at 6:49 PM, brachi brach...@sapiens.com wrote: i did, nothing changed. the leak still exists. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027045.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
Re: [rules-users] permgen leak
how did you changed to mvel? this property?drools.dialect.mvel.strict false or true? i think i tried it with false... -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027048.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
Re: [rules-users] permgen leak
No, set the dialect in the drl itself. Dialect mvel I think. I'll check tomorrow. On Dec 2, 2013, at 7:10 PM, brachi brach...@sapiens.com wrote: how did you changed to mvel? this property?drools.dialect.mvel.strict false or true? i think i tried it with false... -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027048.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
Re: [rules-users] permgen leak
in the drl itself interesting... have a DRL for example? please.. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027050.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
Re: [rules-users] permgen leak
Did you try enabling the JVM flag CMSClassUnloadingEnabled http://stackoverflow.com/questions/3334911/what-does-jvm-flag-cmsclassunloadingenabled-actually-do This typically seems the source of most people’s leaks. Mark On 2 Dec 2013, at 19:10, brachi brach...@sapiens.com wrote: how did you changed to mvel? this property?drools.dialect.mvel.strict false or true? i think i tried it with false... -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027048.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
Re: [rules-users] permgen leak
thanks, I used CMSClassUnloadingEnabled, but this can't help because the GC can't garbage this classes because they are in use somewhere, that is actually the leak. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027052.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
Re: [rules-users] permgen leak
http://www.commonj.com/blogs/2010/11/13/drools-tutorial-by-examples/ On Dec 2, 2013, at 7:41 PM, brachi brach...@sapiens.com wrote: thanks, I used CMSClassUnloadingEnabled, but this can't help because the GC can't garbage this classes because they are in use somewhere, that is actually the leak. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027052.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
Re: [rules-users] permgen leak
At this point we are probably stuck, without a unit test that reproduces the issue. Or better still a patch fixing it. Mark On 2 Dec 2013, at 19:41, brachi brach...@sapiens.com wrote: thanks, I used CMSClassUnloadingEnabled, but this can't help because the GC can't garbage this classes because they are in use somewhere, that is actually the leak. -- View this message in context: http://drools.46999.n3.nabble.com/permgen-leak-tp4027038p4027052.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
