--000e0cd4c08ef92a9e04a1487e47
Content-Type: text/plain;
charseto-8859-1
Content-Transfer-Encoding: quoted-printable
It's strange that moduleName should change like that. Can you reproduce this
issue by printing rete.getFocus() rather than moduleName?
-W
On 18 April 2011 19:25, Grube, Ralf <r.gr...@itcampus.de> 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.
> --------------------------------------------------------------------
>
>
--000e0cd4c08ef92a9e04a1487e47
Content-Type: text/html;
charseto-8859-1
Content-Transfer-Encoding: quoted-printable
It's strange that moduleName should change like that. Can you reproduce
this issue by printing rete.getFocus() rather than
moduleName?<br><br>-W<br><br><br><div class="gmail_quote">On 18 April 2011
19:25, Grube, Ralf <span dir="ltr"><<a
href="mailto:r.gr...@itcampus.de";>r.gr...@itcampus.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204,
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Jess team,<br>
<br>
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.<br>
<br>
Thanks,<br>
Ralf<br>
<br>
p.s. ohh, I have send my first email to a single jess-user only :) So actually
this is my first trial ;)<br>
<br>
-----Ursprüngliche Nachricht-----<br>
Von: Grube, Ralf<br>
Gesendet: Mittwoch, 23. März 2011 16:00<br>
An: '<a href="mailto:jess-u...@sandia.gov";>jess-u...@sandia.gov</a>'<br>
Betreff: Wrong results if using modules and peers in a multithreaded context<br>
<br>
Hi,<br>
<br>
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.<br>
<br>
Basically our execution works like this (the System.outs are there to
understand the results below):<br>
<br>
<code><br>
// a Rete peer<br>
Rete rete String threadName<br>
String moduleName
System.out.println(String.format("<<%s, %d>>
BeforeSettingModule: %s", threadName, rete.hashCode(), moduleName));<br>
<br>
rete.setFocus(moduleName);<br>
rete.setCurrentModule(moduleName);<br>
<br>
moduleName
System.out.println(String.format("<<%s, %d>>
AfterSettingModule: %s", threadName, rete.hashCode(), moduleName));<br>
<br>
// ... some more non Rete related code that consumes a litte
bit time<br>
<br>
moduleName
System.out.println(String.format("<<%s, %d>>
BeforeAddingFacts: %s", threadName, rete.hashCode(), moduleName));<br>
<br>
for (Object fact : getFacts()) {<br>
rete.add(fact);<br>
}<br>
<br>
moduleName
System.out.println(String.format("<<%s, %d>> BeforeRun:
%s", threadName, rete.hashCode(), moduleName));<br>
<br>
rete.run();<br>
</code><br>
<br>
I have logged the current thread name together with the used Rete hashCode to
show:<br>
1. each thread always works on the same Rete instance<br>
2. each thread uses its own Rete instance<br>
<br>
Here is an excerpt of the results:<br>
<br>
<<pool-1-thread-13, 3779465>> BeforeSettingModule: 553486623<br>
<<pool-1-thread-13, 3779465>> AfterSettingModule: 553486625<br>
<<pool-1-thread-11, 7866553>> AfterSettingModule: 553486625<br>
<<pool-1-thread-11, 7866553>> BeforeAddingFacts: 553486625<br>
<<pool-1-thread-9, 12910198>> BeforeRun: 553486625<br>
<<pool-1-thread-11, 7866553>> BeforeRun: 553486625<br>
<<pool-1-thread-6, 2780950>> BeforeRun: 553486625<br>
<<pool-1-thread-7, 11541827>> BeforeSettingModule: 553486625<br>
<<pool-1-thread-7, 11541827>> AfterSettingModule: 553486624<br>
<<pool-1-thread-7, 11541827>> BeforeAddingFacts: 553486624<br>
<<pool-1-thread-15, 28571894>> BeforeSettingModule: 553486623<br>
<<pool-1-thread-15, 28571894>> AfterSettingModule: 553486625<br>
<<pool-1-thread-15, 28571894>> BeforeAddingFacts: 553486625<br>
<<pool-1-thread-7, 11541827>> BeforeRun: 553486625<br>
<<pool-1-thread-13, 3779465>> BeforeAddingFacts: 553486625<br>
<<pool-1-thread-11, 7866553>> BeforeSettingModule: 553486625<br>
<<pool-1-thread-11, 7866553>> AfterSettingModule: 553486626<br>
<<pool-1-thread-11, 7866553>> BeforeAddingFacts: 553486626<br>
<<pool-1-thread-1, 15628820>> BeforeRun: 553486625<br>
<<pool-1-thread-13, 3779465>> BeforeRun: 553486626<br>
<br>
<br>
The erroneous result is produced by 'pool-1-thread-13' here.<br>
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.<br>
The problem causes round about 1% of our results to be wrong. The error rate
increases if increasing the number of threads.<br>
<br>
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().<br>
<br>
<br>
<br>
Regards,<br>
Ralf Grube<br>
<br>
<br>
E-Mail: <a href="mailto:r.gr...@itcampus.de";>r.gr...@itcampus.de</a><br>
<br>
Tel: +49. 341. 4 92 87 55<br>
Fax: +49. 341. 4 92 87 01<br>
<br>
<a href="http://www.itcampus.eu"; target="_blank">http://www.itcampus.eu</a><br>
_______________________________________________<br>
<br>
itCampus Software- und Systemhaus GmbH<br>
Nonnenstraße 42 | 04229 Leipzig<br>
<br>
// a Software AG Company //<br>
<br>
Court of Registry: Amtsgericht Leipzig HRB 15872<br>
CEO: Dr. Andreas Lassmann<br>
CTO: Tobias Schmidt<br>
______________________________________________<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--------------------------------------------------------------------<br>
To unsubscribe, send the words 'unsubscribe jess-users <a
href="mailto:y...@address.com";>y...@address.com</a>'<br>
in the BODY of a message to <a
href="mailto:majord...@sandia.gov";>majord...@sandia.gov</a>, NOT to the list<br>
(use your own address!) List problems? Notify <a
href="mailto:owner-jess-us...@sandia.gov";>owner-jess-us...@sandia.gov</a>.<br>
--------------------------------------------------------------------<br>
<br>
</blockquote></div><br>
--000e0cd4c08ef92a9e04a1487e47--
--------------------------------------------------------------------
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.
--------------------------------------------------------------------
