<div dir="ltr"><br> I think that even with rulebase partitions, we should continue to support current execution mode. So, we should keep a rulebase configuration that basically allow the user to defines: either single-thread (as it is today) or multi-thread (as we are trying to achieve) execution.<br>
<br> Having that in mind, in the multi-thread mode:<br><br>
(A) What does "parallel evaluation of a rulebase" mean? Is it designed<br>
to optimise, for example, two threads processing a stateless and<br>
stateful session?<br> Means that rules that do not share nodes, being independent of each other (from an evaluation perspective), will be evaluated in parallel. This is very common scenario and a desidered feature in CEP engines.<br>
<br>
(B) Are there only two partitions, both of which are invisible to the<br>
user? Is there any value in allowing user-defined partitions?<br>
There will be as many partitions as the compiler can create for the given set of rules. Rules that share more nodes, are more difficult to partition, while rules that are independent from an LHS point of view, are easier to parallelize. In my opinion, the only thing that may be helpful to expose and allow the user to control is the maximum size of the thread pool that is used to propagate facts. Even that I'm not sure is so helpful, because it is complex to fine tune such things, since the partitioning is completely dependent on the rules added to the rulebase.<br>
<br>
(C) Does the partition used depend upon what type of session is used<br>
(i.e. stateless always uses the partition without an agenda whereas<br>
stateful always uses the partition with an agenda)?<br>
The partitioning of the rulebase is dependent upon the rules in the rulebase and nothing more. But that is different from the agenda. The agenda issue is much more complex, because even with partitions we can keep a single deterministic agenda (as long as it is not in active mode - runUntilHalt). Now, if the agenda is in active mode, or if we have multiple agendas (1 per partition, for instance), then the engine behavior becomes indeterministic. This is a common scenario in CEP systems that have multiple different "queries" running over the same set of streams, trying to detect and act upon them as soon as they are detected, and event streams are indeterministic by their own nature. In common rules engines scenarios, I'm not sure we can run in this indeterministic mode.<br>
<br>
(D) Can a rule sometimes be deterministic and sometimes not (i.e.<br>
depends upon the type of session)?<br> It will always depend on the set of rules (the rulebase), not the type of session. One rule is always deterministic when considered in isolation, but two or more rules may or may not be deterministic in relation to each other. Just remember Eisten's Relativity Theory... ;)<br>
<br> []s<br> Edson<br><br><div class="gmail_quote">2008/8/1 Anstis, Michael (M.) <span dir="ltr"><<a href="mailto:manstis1@ford.com">manstis1@ford.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Mark,<br>
<br>
A few questions:-<br>
<br>
(A) What does "parallel evaluation of a rulebase" mean? Is it designed<br>
to optimise, for example, two threads processing a stateless and<br>
stateful session?<br>
<br>
(B) Are there only two partitions, both of which are invisible to the<br>
user? Is there any value in allowing user-defined partitions?<br>
<br>
(C) Does the partition used depend upon what type of session is used<br>
(i.e. stateless always uses the partition without an agenda whereas<br>
stateful always uses the partition with an agenda)?<br>
<br>
(D) Can a rule sometimes be deterministic and sometimes not (i.e.<br>
depends upon the type of session)?<br>
<br>
Cheers,<br>
<br>
Mike<br>
<div><div></div><div class="Wj3C7c"><br>
-----Original Message-----<br>
From: <a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a><br>
[mailto:<a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>] On Behalf Of Mark Proctor<br>
Sent: 01 August 2008 07:05<br>
To: Rules Users List<br>
Subject: [rules-users] determinism with rulebase partitioning<br>
<br>
We have rulebase partitioning almost working, this allows parallel<br>
evaluation of a rulebase. For stateless lessions with no agenda this<br>
will allow for much faster executions, where you don't care about<br>
deterministic execution. However for deterministic execution its more<br>
complicated. The current plan is to have an agenda per parition, which<br>
means that we no longer have rulebase wide deterministic execution<br>
order, only with the partition itself. The user is unlikely to be aware<br>
of the created partitions, so won't be aware of the unditermistic<br>
behavour of their rulebase. Anyone have any input on mechanisms users<br>
can do to help the rulebase know what needs to be executed<br>
deterministically and what doesn't?<br>
<br>
Mark<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>
</div>