The "current module" is the one into which new constructs will be
added; it's unrelated to actual execution of the engine. Since the
Rete network is shared among all peers, the current module is shared,
as well. If you change it from one thread, the changes will be visible
in other threads. Peers are intended for situations in which the Rete
network is fixed once initially created; what you're showing should
not normally be an issue in production. The intent is that no further
new code should be compiled after the peers are created, or at least
not after they are running.
On Apr 18, 2011, at 1:25 PM, Grube, Ralf wrote:
Hi Jess team,
I am not sure whether the email has reached you a month ago. So I
start a second trial here and would be glad if you could take a look
on this issue.
Thanks,
Ralf
p.s. ohh, I have send my first email to a single jess-user only :)
So actually this is my first trial ;)
-----Ursprüngliche Nachricht-----
Von: Grube, Ralf
Gesendet: Mittwoch, 23. März 2011 16:00
An: 'jess-u...@sandia.gov'
Betreff: Wrong results if using modules and peers in a multithreaded
context
Hi,
we have seen some nondeterministic behavior if executing rules with
multiple threads on different Rete peers. Our rule base is scoped by
modules which seems to cause the problems.
Basically our execution works like this (the System.outs are there
to understand the results below):
<code>
// a Rete peer
Rete rete String threadName
String moduleName System.out.println(String.format("<<%s, %d>>
BeforeSettingModule: %s", threadName, rete.hashCode(), moduleName));
rete.setFocus(moduleName);
rete.setCurrentModule(moduleName);
moduleName System.out.println(String.format("<<%s, %d>>
AfterSettingModule: %s", threadName, rete.hashCode(), moduleName));
// ... some more non Rete related code that consumes a litte bit
time
moduleName System.out.println(String.format("<<%s, %d>>
BeforeAddingFacts: %s", threadName, rete.hashCode(), moduleName));
for (Object fact : getFacts()) {
rete.add(fact);
}
moduleName System.out.println(String.format("<<%s, %d>>
BeforeRun: %s", threadName, rete.hashCode(), moduleName));
rete.run();
</code>
I have logged the current thread name together with the used Rete
hashCode to show:
1. each thread always works on the same Rete instance
2. each thread uses its own Rete instance
Here is an excerpt of the results:
<<pool-1-thread-13, 3779465>> BeforeSettingModule: 553486623
<<pool-1-thread-13, 3779465>> AfterSettingModule: 553486625
<<pool-1-thread-11, 7866553>> AfterSettingModule: 553486625
<<pool-1-thread-11, 7866553>> BeforeAddingFacts: 553486625
<<pool-1-thread-9, 12910198>> BeforeRun: 553486625
<<pool-1-thread-11, 7866553>> BeforeRun: 553486625
<<pool-1-thread-6, 2780950>> BeforeRun: 553486625
<<pool-1-thread-7, 11541827>> BeforeSettingModule: 553486625
<<pool-1-thread-7, 11541827>> AfterSettingModule: 553486624
<<pool-1-thread-7, 11541827>> BeforeAddingFacts: 553486624
<<pool-1-thread-15, 28571894>> BeforeSettingModule: 553486623
<<pool-1-thread-15, 28571894>> AfterSettingModule: 553486625
<<pool-1-thread-15, 28571894>> BeforeAddingFacts: 553486625
<<pool-1-thread-7, 11541827>> BeforeRun: 553486625
<<pool-1-thread-13, 3779465>> BeforeAddingFacts: 553486625
<<pool-1-thread-11, 7866553>> BeforeSettingModule: 553486625
<<pool-1-thread-11, 7866553>> AfterSettingModule: 553486626
<<pool-1-thread-11, 7866553>> BeforeAddingFacts: 553486626
<<pool-1-thread-1, 15628820>> BeforeRun: 553486625
<<pool-1-thread-13, 3779465>> BeforeRun: 553486626
The erroneous result is produced by 'pool-1-thread-13' here.
As you can see it has currentModule '553486625' before adding the
facts and before running the engine the current module suddenly is
'553486626'. In this example a suspect could be 'pool-1-thread-11'
because it changes the module just before the erroneous log. But
this is not verified.
The problem causes round about 1% of our results to be wrong. The
error rate increases if increasing the number of threads.
The problem disappears if replacing the Rete peer by a separate Rete
instance that has its own rule base. So it is only related to
Rete.getPeer().
Regards,
Ralf Grube
E-Mail: r.gr...@itcampus.de
Tel: +49. 341. 4 92 87 55
Fax: +49. 341. 4 92 87 01
http://www.itcampus.eu
_______________________________________________
itCampus Software- und Systemhaus GmbH
Nonnenstraße 42 | 04229 Leipzig
// a Software AG Company //
Court of Registry: Amtsgericht Leipzig HRB 15872
CEO: Dr. Andreas Lassmann
CTO: Tobias Schmidt
______________________________________________
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users
y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov
.
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences, Sandia National Laboratories
PO Box 969, MS 9012, Livermore, CA 94550
http://www.jessrules.com
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
--------------------------------------------------------------------
