Re: [rules-users] switching off JIT compiler in 5.4.0.Final
Hi Willem, The only thing that I managed to do before Mario fixed the issue for me in 5.4.1.Final was to include a modified version of MvelConstraint in my own code (of course earlier in the classpath so that it replaced the one from drools) and changing the value of static member JIT_THRESOLD to Integer.MAX_VALUE Quick hoax, but it could help Date: Tue, 2 Oct 2012 08:20:53 +0200 From: wil...@van.asperen.org To: rules-users@lists.jboss.org Subject: [rules-users] switching off JIT compiler in 5.4.0.Final Dear List, Does anyone know of a way to disable JIT in 5.4.0.Final? There is a snag in that version that seems to not play nice with my application. If there is a way to disable it then I could just bridge the time until 5.4.1.Final is released. I have tried the following: -Dmvel.disable.jit=true and -Ddrools.permgenThreshold=0 but still the same issue. Thanks, Willem ___ 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] Package footprint
Hi, Thanks for the replies. I'm actually working with a big number of large rule sets (ranging from 100 rules to up to 3000), which are generated based on another proprietary language. These are not used system wide, but on a user per user basis and loaded dynamically In itself, the system handles itself well, as compiled packages are persisted on disk and loaded only when a user requires it. Thing is, the memory footprint (and the size of the persisted packages) has increased significantly when migrating from 4.0.7 to 5.4.0.Final (20% to 30% for the large ones) and I am trying to find ways of trimming this down as much as I can. Going from a package name of 12 characters to 1 actually and rule names to 3-4 characters shaved off 5-10% in most cases, so not so trivial :-) Unfortunately, reducing the number of rules is not a option in my case, so any advice (or explanation on the increase) is most welcome Date: Thu, 13 Sep 2012 01:42:47 -0700 From: dso...@gmail.com To: rules-users@lists.jboss.org Subject: Re: [rules-users] Package footprint I agree with Wolfgang... can you give us an idea of the rules you are working with? Actually: - using shorter names might be a last-resort, unless you were using really long names in the first place - do not use redundant code is a good practice anyway! - agreed, evals are evils :) - changing the DialectConfigurations is absolutely dangerous, do that at your own risk :) -- View this message in context: http://drools.46999.n3.nabble.com/Package-footprint-tp4019721p4019735.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] Guvnor Declarative Model
Exactly what I was thinking about, but I wanted to check first if I could reuse drools' bytecode generation instead of adding another thirdparty to the mix (one of my previous questions actually). I do want to avoid messing with custom classloaders as much as I can :-) From what I've seen, it doesn't seem to be easily reusable though Date: Mon, 10 Sep 2012 17:33:43 +0200 From: vincent.legen...@eurodecision.com To: rules-users@lists.jboss.org Subject: Re: [rules-users] Guvnor Declarative Model Ok, not simple indeed ... And why can't you generate a POJO instead of declarative fact ? De: Jean-Paul Shemali jshem...@hotmail.com À: rules-users@lists.jboss.org Envoyé: Lundi 10 Septembre 2012 10:06:43 Objet: Re: [rules-users] Guvnor Declarative Model Simply by not writing them in drools, but in another (proprietary) language, which in turn gets translated to drools at runtime. Of course there's nothing really simple about the translation and how the actual facts get generated Date: Sat, 8 Sep 2012 23:53:47 +0200 From: vincent.legen...@eurodecision.com To: rules-users@lists.jboss.org Subject: Re: [rules-users] Guvnor Declarative Model How can you declare your facts (or rules) if you don't know beforehand the structure of the POJO to use ? ___ 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] Guvnor Declarative Model
Simply by not writing them in drools, but in another (proprietary) language, which in turn gets translated to drools at runtime. Of course there's nothing really simple about the translation and how the actual facts get generated Date: Sat, 8 Sep 2012 23:53:47 +0200 From: vincent.legen...@eurodecision.com To: rules-users@lists.jboss.org Subject: Re: [rules-users] Guvnor Declarative Model How can you declare your facts (or rules) if you don't know beforehand the structure of the POJO to use ? ___ 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] Guvnor Declarative Model
Thanks for quick answers guys! I just realized the original thread never made it trough to the list (the user didn't register probably) the original poster had the same issue on Guvnor, hence the title. Edson I've opened https://issues.jboss.org/browse/JBRULES-3621 for this Unfortunately, I don't have any workaround for this, as I don't know beforehand the structure of the POJO to use (in my use case, there is an additional layer on top of drools, and I don't know the facts). Although I'm not 100% blocked by this, is it possible to reuse the drools code generator manually? That way I could workaround it by generating the class myself and skip the constructor generation? Date: Fri, 7 Sep 2012 15:45:02 +0200 From: vincent.legen...@eurodecision.com To: rules-users@lists.jboss.org Subject: Re: [rules-users] Guvnor Declarative Model a workaround could be to use a java pojo, not a declared fact From: Edson Tirelli ed.tire...@gmail.com To: Rules Users List rules-users@lists.jboss.org Sent: Friday, September 7, 2012 3:43:04 PM Subject: Re: [rules-users] Guvnor Declarative Model Ouch, more than 255 fields? As of 5.4.x there is no workaround, the engine always tries to generate the constructor. Can you please open a JIRA and we will fix this for the next release? Thank you, Edson On Fri, Sep 7, 2012 at 9:05 AM, JP Chemali jshem...@hotmail.com wrote: Hi guys, I just stumbled into the same issue in 5.4.0.Final, I think this is caused by https://issues.jboss.org/browse/JBRULES-2652 When declaring a type, a constructor with all fields as parameters is generated automatically, but this causes in our case to hit a barrier of the Java language because the generated constructor has more than 255 parameters Anyone knows if this generation can be skipped (annotation or something else), maybe a safeguard not to generate the constructor when the limit is reached would be nice too? -- View this message in context: http://drools.46999.n3.nabble.com/Guvnor-Declarative-Model-tp4019419p4019637.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 -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.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] Migrating from 4.0.7 to 5.4.0.Final
Hi again mario, Yes in my case it would be nice for generated classes to be garbage collected when no longer referenced : for long-lived virtual machines where rules are changed a lot, you really hit the max perm gen quickly enough. I guess what you are describing is a production environment where rules are loaded/compiled once in the VM's life (startup time most probably) and that's it. That's not my case, it's rather the reverse in some cases, as specialized users can test their rule sets in the same environment as the production one and choose to release them. Your option to control JITing space looks like a good way to keep things in check. Would it possible to ensure if we set the space to 0, it actually disables it? That would ensure that everything runs in my calling threads and gets garbage collected right? Again thanks a mil for your help Date: Wed, 4 Jul 2012 06:31:00 -0700 From: mario.fu...@gmail.com To: rules-users@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-tp4018215p4018465.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] Migrating from 4.0.7 to 5.4.0.Final
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: jshem...@hotmail.com To: rules-users@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-tp4018215.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
