Thanks for your explanation Edson, it makes sense now I think!
Basically what you are saying is that there is a limit, beyond which is no
longer feasible to use more ORs on a rule.
Edson Tirelli-4 wrote
You are trying to avoid the issue. As reported by others, your
conditions should be
Thank you all for your feedback, I will try to implement at least the part of
collapsing the multiple evals() into a single one.
Edson Tirelli-4 wrote
Also, I just read the example in your link where you have multiple
accumulates in a single rule... that is *bad*
The accumulate()
Hi,
Recently I was trying to optimize the rule compilation time for my KB (~4K
rules).
I do a full KB compilation every night, as most of the rules are dynamic
generated/converted and managed by the business operators.
The compile time was not very good (around 3 hours on a 8 core Xeon CPU),
but
laune wrote
Well, I do mind the nonsense Number(). There's no point in
discussing this if you don't post an exact image of your rule.
-W
There is a point, because the rule I've posted compiles and causes the same
problem, I've just removed redundant code to expose the problematic
I understand that the rule looks pointless and under-optimized, but it's the
only way I could represent this kind of rule in an automated way (I didn't
write the rule by hand). Basically with these rules I try to pre-compute the
amount of some products on the WM (using count() inside a accumulate
Hi,
These rules are all auto-generated every day, and I don't control what is
going into them, so this kind of optimizations won't work for me. The basic
problem here, is that I have tons of rules that count facts
(PortfolioProducts) and use the result as rule conditions.
Some conditions could
I have a question regarding eval() use. My rulebase is around ~3k rules, most
of them are auto-generated by templates, and they end up looking like this:
rule CONFIG_114
salience 0
when
client: Client()
contextProd: PortfolioProduct(prodAdded == true, productId ==
PROFESSIONAL)
Hi,
We are having the same problem with a similar setup (drools 5.2.0 Final)
using stateless sessions and camel integration, using a KB with ~3000 rules.
Session memory is never reclaimed, and after some hours we got an out of
memory error. We still dont know the cause, but the profiler shows