You are trying to avoid the issue. As reported by others, your conditions should be inside the patterns, not in "or'd" evals in the end, and yes, it is possible to generate rules like that in an automated program.
Now, the reason it is taking so long is because of the "or"s. I don't think there is any bug there. Just for you to understand, an OR is just syntax sugar for multiple rules. So if you have a rule that says:
A() or B()
The engine is actually creating 2 rules:
rule 1 when
A()
...
rule 2 when
B()
...
I.e., it generates all possible combinations of rules, one for each of your logical branches.
Now, I quickly counted 26 "or"s in your rule. It is quite possible that the engine is generating all possible combinations of rules for all your ORs, and that is roughly (there are some factors that influence the number of rules): 2^26 == 67108864 rules. To compile 67 million rules, it can indeed take some time.
I don't know for sure if that is the case without looking at your application, but to solve your problem you should fix your rule generation, not look for a problem elsewhere.
Edson
On Tue, Jul 24, 2012 at 9:29 AM, fx242
<drools@fx242.com> wrote:
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
function) resulting in a Number(), and then on the last condition I evaluate
some arbitrary arithmetic operation using the variables inside the Number()
object.
For more details for examples see my previous post where I've tried to
address this issue:
http://drools.46999.n3.nabble.com/drools-arithmetics-without-eval-td3823232.html
So, considerations apart of the way the rule is written, I still think there
is a bug or something similar on the RETE compiler, that causes this rule to
be processed in a very expensive way. Can someone confirm this, and try to
sugest an alternative? Maybe It's something that is already fixed on newer
versions as sugested by Esteban?
Regards,
Tiago Lopes
--
View this message in context: http://drools.46999.n3.nabble.com/Slow-compilation-4h-for-a-single-rule-tp4018855p4018870.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com