Date: Mon, 25 Jun 2012 00:01:16 -0700 From: jshemali(a)hotmail.com To: rules-users(a)lists.jboss.org Subject: [rules-users] Migrating from 4.0.7 to 5.4.0.Final Hi all, I'm currently in the process of migrating an application using drools 4.0.7 to 5.4.0.Final and I've stumbled into a few issues with the new version that I find disturbing: - Our unit tests failed because the JVM ran out of perm gen space, which looks odd as in 4.0.7 we've had quite a margin to start with. - Doing several Yourkit analysis, I finally find classloading leaks: * *org.drools.rule.builder.dialect.asm.ClassGenerator.EMPTY_METHOD_BODY* is a static instance which will hold to the last instance of InternalClassLoader created * *org.drools.rule.constraint.MvelConstraint* uses an ExecutorHolder that spawns daemon threads and keeps them in a pool. Problem is these threads create class loaders, and can only be garbage collected when the thread dies, meaning never in my case... - I've quick fixed both issues, the second one by simply disabling the thread pool. - Once this is done, the perm gen behaves correctly, but the execution times are 2-3 times slower on very large set of rules (~1000). Looking at Yourkit analysis again, I see that the number of classes generated and the perm gen consumption is about 3 times higher in 5.4.0.Final. I honestly don't know how to address this. I've tried to find some other posts concerning these issues, to no avail. I don't see any work around this, short of code changes, and for reducing the number of generated classes I simply have no idea. Please correct me if I am wrong, any help would be greatly appreciated -- View this message in context: http://drools.46999.n3.nabble.com/Migrating-from-4-0-7-to-5-4-0-Final-tp4... 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

Hello, I'm considering migrating one of our key (several thousands of rules, stateful sessions, and beans with propertyChangeSupport) application from 4.0.7 to 5.4 and your message isn't very encouraging :) Have you opened some JIRA's or have you made some other discoveries ? I will post my experiences here if I discover something but I maybe will have to wait until august before I can start with the migration. -Patrick -- View this message in context: http://drools.46999.n3.nabble.com/Migrating-from-4-0-7-to-5-4-0-Final-tp4... 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

Hi again all, Am i the only one noting these issues on the version? If this is not the right place to discuss this, could someone point me in the right direction (do I enter an issue in JIRA with potential patches, ...)? Thanks in advance > Date: Mon, 25 Jun 2012 00:01:16 -0700 > From: jshemali(a)hotmail.com > To: rules-users(a)lists.jboss.org > Subject: [rules-users] Migrating from 4.0.7 to 5.4.0.Final > > Hi all, > > I'm currently in the process of migrating an application using drools 4.0.7 > to 5.4.0.Final and I've stumbled into a few issues with the new version that > I find disturbing: > > - Our unit tests failed because the JVM ran out of perm gen space, which > looks odd as in 4.0.7 we've had quite a margin to start with. > - Doing several Yourkit analysis, I finally find classloading leaks: > * *org.drools.rule.builder.dialect.asm.ClassGenerator.EMPTY_METHOD_BODY* > is a static instance which will hold to the last instance of > InternalClassLoader created > * *org.drools.rule.constraint.MvelConstraint* uses an ExecutorHolder that > spawns daemon threads and keeps them in a pool. Problem is these threads > create class loaders, and can only be garbage collected when the thread > dies, meaning never in my case... > - I've quick fixed both issues, the second one by simply disabling the > thread pool. > - Once this is done, the perm gen behaves correctly, but the execution times > are 2-3 times slower on very large set of rules (~1000). Looking at Yourkit > analysis again, I see that the number of classes generated and the perm gen > consumption is about 3 times higher in 5.4.0.Final. I honestly don't know > how to address this. > > I've tried to find some other posts concerning these issues, to no avail. I > don't see any work around this, short of code changes, and for reducing the > number of generated classes I simply have no idea. > > Please correct me if I am wrong, any help would be greatly appreciated > > -- > View this message in context: http://drools.46999.n3.nabble.com/Migrating-from-4-0-7-to-5-4-0-Final-tp4... > 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 _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Date: Wed, 4 Jul 2012 06:31:00 -0700 From: mario.fusco(a)gmail.com To: rules-users(a)lists.jboss.org Subject: Re: [rules-users] Migrating from 4.0.7 to 5.4.0.Final Hi again, You are looking at the correct branch and I didn't change the MvelConstraint class indeed. What I did is to change the ClassGenerator to try to avoid the creation of new ClassLoaders (when possible). Said that what I don't understand is why you expect the generated classes to be garbage collected. They are used to evaluate the constraints in your rules, so I don't think they could/should be CG'd anyway. Am I missing something? Anyway we are realizing that the required PermGen space could be a problem especially if you have a big rule base, so I am going to add a configuration option that will allow you to define how many space you want to give to these JITted constraints. Once the engine will hit this limit it will just stop JITting further constraints leaving them run in interpreted mode. Hopefully the users will be able to find a good trade-off between performances and memory occupation in this way. Does this make sense to you? Mario -- View this message in context: http://drools.46999.n3.nabble.com/Migrating-from-4-0-7-to-5-4-0-Final-tp4... 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

Yes, of course it will be possible, even if my suggestion is to avoid this in production otherwise you will have ALL the constraints running in interpreted mode. Actually you could already achieve this if you can rebuild drools from the sources (you already did it, so I assume it won't be a problem). If you want to try open the class MvelConstraint and modify the constant JIT_THRESOLD. That constant defines after how many times a constraint can be evaluated in interpreted mode before to get JITted, so if you set it to a very high value (e.g. Integer.MAX_VALUE) you should be able to completely avoid any JITting. Let me know if this works. I hope this helps, Mario