Re: [rules-users] Conflict resolution strategy - before vs after Phreak impl
Mark, This was a really useful post, going into some detail on behaviour and the underlying reasoning for the Drools implementation, especially the 6.X stuff. I've removed a whole bunch of salience mess as a result as well, which is always good for code quality. A question though - if rules in multiple different files become eligble for firing at the same time, is their ordering something that is readily predictable? Thanks Borris On Monday 28/07/2014 17:11, Mark Proctor wrote: 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. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Conflict resolution strategy - before vs after Phreak impl
If they are in different files, I recommend that they are in different agenda-grounds. They’ll continue to be prioritised in load order, so you’ll have two with load order 1, two with load order 2, two with load order 3 etc. Mark On 5 Aug 2014, at 19:12, Borris bor...@chaos.org.uk wrote: Mark, This was a really useful post, going into some detail on behaviour and the underlying reasoning for the Drools implementation, especially the 6.X stuff. I've removed a whole bunch of salience mess as a result as well, which is always good for code quality. A question though - if rules in multiple different files become eligble for firing at the same time, is their ordering something that is readily predictable? Thanks Borris On Monday 28/07/2014 17:11, Mark Proctor wrote: 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. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Conflict resolution strategy - before vs after Phreak impl
In version 5.x of Drools I see that it offered configurable conflict resolver 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 network. 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 default resolver. 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 https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/common/AgendaGroupQueueImpl.java#L68 . 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 https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/conflict/PhreakConflictResolver.java#L52 . 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 org.drools.conflict package. /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 salience, etc. 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 @ http://blog.athico.com/2013/11/rip-rete-time-to-get-phreaky.html, 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: http://drools.46999.n3.nabble.com/Conflict-resolution-strategy-before-vs-after-Phreak-impl-tp4030521.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Conflict resolution strategy - before vs after Phreak impl
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. Mark On 28 Jul 2014, at 16:31, mikerod mjr4...@gmail.com wrote: In version 5.x of Drools I see that it offered configurable conflict resolver 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 network. 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 default resolver. 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 https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/common/AgendaGroupQueueImpl.java#L68 . 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 https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/conflict/PhreakConflictResolver.java#L52 . Why was this implementation chosen? Is it discussed or documented anywhere? Was it determined that this performs better than anything else or that there
Re: [rules-users] Conflict resolution strategy - before vs after Phreak impl
Thanks Mark for that explanation! I'd say that certainly addresses the questions I had and I can understand the points you make. We do intend to move to the Phreak implementation still. I was just looking for some clarity on this topic as we dealt with things, which I now have. -- View this message in context: http://drools.46999.n3.nabble.com/Conflict-resolution-strategy-before-vs-after-Phreak-impl-tp4030521p4030523.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
