There is a class called BitSet, which grows the number of bits.
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: for (int i = Math.min(wordsInUse, set.wordsInUse) - 1; i >= 0; i--) {if ((words[i] & set.words[i]) != 0) {
But we can investigate and see if it adds any noticeable performance. In the meantime the kbuilder should probably throw an exception.
Mark
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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
|
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
