Re: [rules-users] rule infinitely loops, appears to be depending on naming on variable
In my opinion to have a Java Bean (or a DRL type declaration that is exactly the same for what regards this issue) with more than 20 fields is a code smell and however something very hard to maintain. I must admit that I've been tempted to use an int as bitmask when I developed that feature, but in the end I decided to go with a long thinking that in this way I could be sure to cover everybody's needs. Evidently I was wrong. That said I will experiment developing a custom made BitSet to check if I can address this issue without paying a performance penalty. Indeed I wouldn't like to have a performance loss (together with an higher memory occupation) for something that I still consider an extreme edge case. So what I will do in the short term will be to just disable the property reactive feature for types with more than 64 fields and emit a compilation warning when this happens. Mario -- View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020166.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] rule infinitely loops, appears to be depending on naming on variable
Btw JVM JIT won't unroll the loop. It can only do this when the same instance is used repeatedly in the same method. If the instance used in the method changes on each invocation, as ours does, it's not possible for JIT to unroll the loop. Mark On 8 Oct 2012, at 15:21, Mario Fusco mario.fu...@gmail.com wrote: In my opinion to have a Java Bean (or a DRL type declaration that is exactly the same for what regards this issue) with more than 20 fields is a code smell and however something very hard to maintain. I must admit that I've been tempted to use an int as bitmask when I developed that feature, but in the end I decided to go with a long thinking that in this way I could be sure to cover everybody's needs. Evidently I was wrong. That said I will experiment developing a custom made BitSet to check if I can address this issue without paying a performance penalty. Indeed I wouldn't like to have a performance loss (together with an higher memory occupation) for something that I still consider an extreme edge case. So what I will do in the short term will be to just disable the property reactive feature for types with more than 64 fields and emit a compilation warning when this happens. Mario -- View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020166.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] rule infinitely loops, appears to be depending on naming on variable
The only danger is with generated code, where you don't have full control over the final number of attributes. I would assume that, in those cases, one should avoid @propertyReactive altogether if there is a danger of exceeding the threshold? A warning would be ignored in an automatic developement process, potentially ending in loops where @pR is not kicking in as expected :( This is just for clarity, I do agree on the fact that huge bean classes should be used with care Davide -- View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020172.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] rule infinitely loops, appears to be depending on naming on variable
see attached drl.running it with the following inputs will cause the only rule in there to infinitely loop.bankruptcychapternumbert=nullbankruptcychapternumberm=nullall other values are not set.yet removing some of the never used variables from the drl seems to solve this.on the other hand, adding variables of certain names will have the same effect, while other will not.see comments within the drl as to which lines should be added removed to make it run as expected\loop. -- View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158.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] rule infinitely loops, appears to be depending on naming on variable
At the moment, @propertyReactive uses a bit mask internally... and I believe that is limited to 64 bits, which corresponds to 64 fields, less than what you have. I'm not 100% sure since I didn't check, but I have the feeling that it may explain what is going on here.. You have something like 160 fields, which is 128+32.. adding or removing one might indeed make a difference! This may indeed be a (known?) bug or limitation of the current impl, Mario Fusco will be able to provide more insight.. You can easily work around the problem, at least for now, by preventing the loop with updatedArBankruptcyChapterPopulated != No A side question would be: do you really need all those fields in the same class? Wouldn't it be more reasonable to split it them in multiple beans, rather than a single generic Facts class? I'm not familiar with the domain, but the properties seem very hetherogeneous... Also in terms of efficiency and memory consumption, would an average instance of yours have most of those fields populated? Best Davide -- View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020159.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] rule infinitely loops, appears to be depending on naming on variable
Thanks for the quick response. Is there a jira for this or should I open one? I can workaround this for now by arbitrarily splitting the class.. but i guess initializing many of these instead of one may hurt performance. They actually belong all together and all of them are in use by the other rules in the original drl. perhaps i will simply use the no-loop attribute. -- View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020160.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] rule infinitely loops, appears to be depending on naming on variable
There is a class called BitSet, which grows the number of bits.http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/BitSet.javaThis uses an array of longs instead. But i'm really reluctant to use this, because it adds overhead to our currently very lightweight operation, it has to create a for loop:publicbooleanintersects(BitSetset){for(inti=Math.min(wordsInUse,set.wordsInUse)-1;i=0;i--) { if((words[i]set.words[i])!=0) {returntrue; } }returnfalse;}But we can investigate and see if it adds any noticeable performance. In the meantime the kbuilder should probably throw an exception.MarkOn 5 Oct 2012, at 21:44, Davide Sottara dso...@gmail.com wrote:At the moment, @propertyReactive uses a bit mask internally... and I believethat is limited to 64 bits, which corresponds to 64 fields, less than whatyou have. I'm not 100% sure since I didn't check, but I have the feeling that it mayexplain what is going on here..You have something like 160 fields, which is 128+32.. adding or removing onemight indeed make a difference!This may indeed be a (known?) bug or limitation of the current impl, MarioFusco will be able to provide more insight..You can easily work around the problem, at least for now, by preventing theloop with updatedArBankruptcyChapterPopulated != "No"A side question would be: do you really need all those fields in the sameclass? Wouldn't it be more reasonable to split it them in multiple beans,rather than a single generic "Facts" class? I'm not familiarwith the domain, but the properties seem very hetherogeneous...Also in terms of efficiency and memory consumption, would an averageinstance of yours have most of those fields populated?BestDavide--View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020159.htmlSent from the Drools: User forum mailing list archive at Nabble.com.___rules-users mailing listrules-users@lists.jboss.orghttps://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] rule infinitely loops, appears to be depending on naming on variable
You could implement a custom bit set with internal loops that are apt to be unrolled by the jit.From: Mark Proctor mproc...@codehaus.org To: Rules Users List rules-users@lists.jboss.org Sent: Friday, October 5, 2012 7:17 PM Subject: Re: [rules-users] rule infinitely loops, appears to be depending on naming on variable
There is a class called BitSet, which grows the number of bits.http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/BitSet.javaThis uses an array of longs instead. But i'm really reluctant to use this, because it adds overhead to our currently very lightweight operation, it has to create a for loop:publicbooleanintersects(BitSetset){for(inti=Math.min(wordsInUse,set.wordsInUse)-1;i=0;i--) { if((words[i]set.words[i])!=0) {returntrue; } }returnfalse;}But we can investigate and see if it adds any noticeable performance. In the meantime the kbuilder should probably throw an exception.MarkOn 5 Oct 2012, at 21:44, Davide Sottara dso...@gmail.com wrote:At the moment, @propertyReactive uses a bit mask internally... and I believethat is limited to 64 bits, which corresponds to 64 fields, less than whatyou have. I'm not 100% sure since I didn't check, but I have the feeling that it mayexplain what is going on here..You have something like 160 fields, which is 128+32.. adding or removing onemight indeed make a difference!This may indeed be a (known?) bug or limitation of the current impl, MarioFusco will be able to provide more insight..You can easily work around the problem, at least for now, by preventing theloop with
updatedArBankruptcyChapterPopulated != "No"A side question would be: do you really need all those fields in the sameclass? Wouldn't it be more reasonable to split it them in multiple beans,rather than a single generic "Facts" class? I'm not familiarwith the domain, but the properties seem very hetherogeneous...Also in terms of efficiency and memory consumption, would an averageinstance of yours have most of those fields populated?BestDavide--View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020159.htmlSent from the Drools: User forum mailing list archive at Nabble.com.___rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users___rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
