Conflict resolution strategies are “magic” things, it means how a set of rules behave
cannot be determined from reading the rules alone, and could potentially change if someone
changes the backend component (possibly without you knowing). Our preference is to ensure
any execution behaviour is encoded and visible in the rules themselves. Over time we’d
rather create additional declarative ways to do this on the rules themselves, rather than
change some magic backend component; such as the experimental declarative agenda we’ve
added. CRS in 6x is different to 5x, it’s now choosing the order or rules to evaluate,
where as 5x the CRS controls the order in which rules are fired. We need to be free to
change these type of things, without worrying about user compatibility - so less we expose
to end suers the better; and as mentioned I consider it an anti-pattern in ease of rule
authoring and maintenance. The only reason why we haven’t removed all of the
implementations is that there is a degree of 5x compatibility in the system still.
Phreak is just depth + load order, so it’s not a big change, all it does is remove the
degree of arbitrary behaviour you were relying on for performance. Depth in 5x meant rules
with the same salience were executed in an arbitrary order, it seems this arbitrary order
was not so arbitrary in your case and makes an impact on performance - but as it’s
arbitrary the repeatability of this cannot be ensured, even across environments let alone
versions. In 6x this is no longer arbitrary, which will allow people more predictability
in their rule executions. Load order is also much easier for people to understand and deal
with, and often avoids the need to use salience at all - it’s also how people’s brains
tend to think. Rules higher up in the file, fire first. We recommend one “agenda-group”
per file, so that it’s easy to keep control of those orders. Salience can still over-ride
this; but over time we have further ideas to completely remove the need for salience. This
didn’t make much sense in 5x as load order was not preserved between kbase updates, so if
you add rules later you lose the load order. In 6x we fixed this, so load order is always
preserved between versions, an thus adding this enhancement makes sense.
So the key takeaway is for future systems it should make them easier to author and with
more predictable performance results.
You can still run the rete engine if you want, it’s available through configuration.
Although it would be better to start working with Phreak, so you can provide feedback to
us, for future improvements.
On 28 Jul 2014, at 16:31, mikerod <mjr4184(a)gmail.com> wrote:
In version 5.x of Drools I see that it offered configurable conflict
strategies. I also read a few different Drools documentation sources that
discussed varieties of "complex" conflict resolution strategies. One source
discussed a tiered implementation by the name of CompositeConflictResolver -
which was @ http://legacy.drools.codehaus.org/Conflict+Resolution
We have been experimenting with uplifting from Drools v5.6.0.Final to a v6.x
version and we noted a fairly significant performance degradation /(a)/.
When digging into some rule logging,
we found that the issue was that our rule load order was not behaving well
in terms of conflict resolution. The "wrong" rule activations were chosen
to go first on the agenda, and this
was causing a lot of unnecessary/redundant "movement" within the Rete
After reading through the documentation on conflict resolution strategies
and noting that it was configurable in Drools v5.x, I started thinking more
about the importance a conflict resolution strategy on performance. Digging
deeper, I believe Drools v5.6.0.Final uses
`org.drools.core.conflict.DepthConflictResolver` as the default resolver
(which is not the CompositeConflictResolver mentioned above interestingly).
In Drools v6.x (around v6.2.x I believe) with Phreak enabled, there is a
`org.drools.core.conflict.PhreakConflictResolver` that is used as the
This raises a few questions:
/1)/ With Phreak enabled, it looks like the conflict resolver is *not*
configurable anymore. I believe this is the case due to these lines
. Why was this configuration options removed?
/2)/ The PhreakConflictResolver does not seem to be doing anything very
sophisticated now. I gather that it respects salience first, then falls
back to rule load order. I found this around these lines
. Why was this implementation chosen? Is it discussed or documented
anywhere? Was it determined that this performs better than anything else or
that there is no significant difference either way? There are about 4
conflict resolver impls in the org.drools.core.conflict package. In Drools
v5.6.x I saw there were 10-11 of them in the similarly purposed
/3)/ (related to /(2)/) Why was the default conflict resolution strategy
changed to PhreakConflictResolver from the DepthConflictResolver used in
v5.6.x? I do not think they are the same based on the source code, however,
I cannot say I fully understand all of the semantics of the
`Activation#getActivationNumber` used in the DepthConflictResolver.
I know that my perf issue /(a)/ noted above could be solved by using
I was wanting to avoid using salience where possible as it
leads to more fragile, less declarative systems. We were able to fix the
perf issue, by simply changing the rule load order anyways. My question is
not specifically asking how to deal with this perf issue. Instead I'm
asking about Drools choice of conflict resolution strategy in v6, as I have
listed in points /1-3/ above.
In the blog post @
I think the sentence,
/"A simple heuristic, based on the rule most likely to result in firings, is
used to select the next rule for evaluation; this delays the evaluation and
firing of the other rules."/
is the only thing I see on the topic of conflict resolution (at least I
think it is). I understand the parts about unlinked and linked rules,
however, when the agenda is populated by multiple activations of the same
salience, that's when things get interesting from the point of view of the
topic discussed here.
I appreciate any feedback with regards to this.
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list