3:23 p.m.
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-dep...
Sent from the Drools: User forum mailing list archive at Nabble.com.
3:44 p.m.
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-dep...
Sent from the Drools: User forum mailing list archive at Nabble.com.
4:51 p.m.
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-dep...
Sent from the Drools: User forum mailing list archive at Nabble.com.
7:17 p.m.
There is a class called BitSet, which grows the number of bits.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-...
This 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:
public boolean intersects(BitSet set) {
for (int i = Math.min(wordsInUse, set.wordsInUse) - 1; i >= 0; i--) {
if ((words[i] & set.words[i]) != 0) {
return true;
}
}
return false;
}
But we can investigate and see if it adds any noticeable performance. In the meantime the
kbuilder should probably throw an exception.
Mark
On 5 Oct 2012, at 21:44, Davide Sottara <dsotty(a)gmail.com> wrote:
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-dep...
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
10:16 p.m.
You could implement a custom bit set with internal loops that are apt to be unrolled by
the jit.
________________________________
From: Mark Proctor <mproctor(a)codehaus.org>
To: Rules Users List <rules-users(a)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-...
This 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:
public boolean intersects(BitSet set) {
for (int i = Math.min(wordsInUse, set.wordsInUse) - 1; i >= 0; i--) {
if ((words[i] & set.words[i]) != 0) {
return true;
}
}
return false;
}
But we can investigate and see if it adds any noticeable performance. In the meantime the
kbuilder should probably throw an exception.
Mark
On 5 Oct 2012, at 21:44, Davide Sottara <dsotty(a)gmail.com> wrote:
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-dep...
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
9:21 a.m.
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-dep...
Sent from the Drools: User forum mailing list archive at Nabble.com.
9:34 a.m.
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.fusco(a)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-dep...
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
9:45 p.m.
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-dep...
Sent from the Drools: User forum mailing list archive at Nabble.com.
4428
days inactive
4432
days old
7 comments
5 participants
participants (5)
-
Davide Sottara -
dec -
Greg Barton -
Mario Fusco -
Mark Proctor