JESS: Wrong results if using modules and peers in a multithreaded context

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

JESS: Wrong results if using modules and peers in a multithreaded context

Grube, Ralf
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: '[hidden email]'
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: [hidden email]

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 [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: JESS: Wrong results if using modules and peers in a multithreaded context

Wolfgang Laun-2

--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 <[hidden email]> 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: '[hidden email]'
> 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: [hidden email]
>
> 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 [hidden email]'
> in the BODY of a message to [hidden email], NOT to the list
> (use your own address!) List problems? Notify [hidden email].
> --------------------------------------------------------------------
>
>

--000e0cd4c08ef92a9e04a1487e47
Content-Type: text/html;
 charseto-8859-1
Content-Transfer-Encoding: quoted-printable

It&#39;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">&lt;<a href="mailto:[hidden email]">[hidden email]</a>&gt;</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: &#39;<a href="mailto:[hidden email]">[hidden email]</a>&#39;<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>
&lt;code&gt;<br>
                // a Rete peer<br>
                Rete rete               String threadName<br>
                String moduleName               System.out.println(String.format(&quot;&lt;&lt;%s, %d&gt;&gt; BeforeSettingModule: %s&quot;, threadName, rete.hashCode(), moduleName));<br>
<br>
            rete.setFocus(moduleName);<br>
            rete.setCurrentModule(moduleName);<br>
<br>
                moduleName              System.out.println(String.format(&quot;&lt;&lt;%s, %d&gt;&gt; AfterSettingModule: %s&quot;, 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(&quot;&lt;&lt;%s, %d&gt;&gt; BeforeAddingFacts: %s&quot;, threadName, rete.hashCode(), moduleName));<br>
<br>
            for (Object fact : getFacts()) {<br>
                rete.add(fact);<br>
                }<br>
<br>
                moduleName              System.out.println(String.format(&quot;&lt;&lt;%s, %d&gt;&gt; BeforeRun: %s&quot;, threadName, rete.hashCode(), moduleName));<br>
<br>
                rete.run();<br>
&lt;/code&gt;<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>
&lt;&lt;pool-1-thread-13, 3779465&gt;&gt; BeforeSettingModule: 553486623<br>
&lt;&lt;pool-1-thread-13, 3779465&gt;&gt; AfterSettingModule: 553486625<br>
&lt;&lt;pool-1-thread-11, 7866553&gt;&gt; AfterSettingModule: 553486625<br>
&lt;&lt;pool-1-thread-11, 7866553&gt;&gt; BeforeAddingFacts: 553486625<br>
&lt;&lt;pool-1-thread-9, 12910198&gt;&gt; BeforeRun: 553486625<br>
&lt;&lt;pool-1-thread-11, 7866553&gt;&gt; BeforeRun: 553486625<br>
&lt;&lt;pool-1-thread-6, 2780950&gt;&gt; BeforeRun: 553486625<br>
&lt;&lt;pool-1-thread-7, 11541827&gt;&gt; BeforeSettingModule: 553486625<br>
&lt;&lt;pool-1-thread-7, 11541827&gt;&gt; AfterSettingModule: 553486624<br>
&lt;&lt;pool-1-thread-7, 11541827&gt;&gt; BeforeAddingFacts: 553486624<br>
&lt;&lt;pool-1-thread-15, 28571894&gt;&gt; BeforeSettingModule: 553486623<br>
&lt;&lt;pool-1-thread-15, 28571894&gt;&gt; AfterSettingModule: 553486625<br>
&lt;&lt;pool-1-thread-15, 28571894&gt;&gt; BeforeAddingFacts: 553486625<br>
&lt;&lt;pool-1-thread-7, 11541827&gt;&gt; BeforeRun: 553486625<br>
&lt;&lt;pool-1-thread-13, 3779465&gt;&gt; BeforeAddingFacts: 553486625<br>
&lt;&lt;pool-1-thread-11, 7866553&gt;&gt; BeforeSettingModule: 553486625<br>
&lt;&lt;pool-1-thread-11, 7866553&gt;&gt; AfterSettingModule: 553486626<br>
&lt;&lt;pool-1-thread-11, 7866553&gt;&gt; BeforeAddingFacts: 553486626<br>
&lt;&lt;pool-1-thread-1, 15628820&gt;&gt; BeforeRun: 553486625<br>
&lt;&lt;pool-1-thread-13, 3779465&gt;&gt; BeforeRun: 553486626<br>
<br>
<br>
The erroneous result is produced by &#39;pool-1-thread-13&#39; here.<br>
As you can see it has currentModule &#39;553486625&#39; before adding the facts and before running the engine the current module suddenly is &#39;553486626&#39;. In this example a suspect could be &#39;pool-1-thread-11&#39; 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:[hidden email]">[hidden email]</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 &#39;unsubscribe jess-users <a href="mailto:[hidden email]">[hidden email]</a>&#39;<br>
in the BODY of a message to <a href="mailto:[hidden email]">[hidden email]</a>, NOT to the list<br>
(use your own address!) List problems? Notify <a href="mailto:[hidden email]">[hidden email]</a>.<br>
--------------------------------------------------------------------<br>
<br>
</blockquote></div><br>

--000e0cd4c08ef92a9e04a1487e47--


--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: JESS: Wrong results if using modules and peers in a multithreaded context

Wolfgang Laun-2
In reply to this post by Grube, Ralf
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 <[hidden email]> 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: '[hidden email]'
> 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: [hidden email]
>
> 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 [hidden email]'
> in the BODY of a message to [hidden email], NOT to the list
> (use your own address!) List problems? Notify [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: JESS: Wrong results if using modules and peers in a multithreaded context

Friedman-Hill, Ernest
In reply to this post by Grube, Ralf
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: '[hidden email]'
> 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: [hidden email]
>
> 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  
> [hidden email]'
> in the BODY of a message to [hidden email], NOT to the list
> (use your own address!) List problems? Notify [hidden email]
> .
> --------------------------------------------------------------------

---------------------------------------------------------
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 [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

AW: JESS: Wrong results if using modules and peers in a multithreaded context

Grube, Ralf
In reply to this post by Grube, Ralf
Hi Wolfgang,

thank you for looking at this.

I have created a log similar to my first post. It additionally contains the getFocus() output.

<<pool-1-thread-8, 18751079>> BeforeSettingModule: getFocus() MAIN ||| getCurrentModule() 553486625
<<pool-1-thread-2, 24622029>> BeforeSettingModule: getFocus() MAIN ||| getCurrentModule() 553486625
<<pool-1-thread-8, 18751079>> AfterSettingModule: getFocus() 553486626 ||| getCurrentModule() 553486626
<<pool-1-thread-2, 24622029>> AfterSettingModule: getFocus() 553486624 ||| getCurrentModule() 553486624
<<pool-1-thread-8, 18751079>> BeforeAddingFacts: getFocus() 553486626 ||| getCurrentModule() 553486624
<<pool-1-thread-2, 24622029>> BeforeAddingFacts: getFocus() 553486624 ||| getCurrentModule() 553486624
<<pool-1-thread-2, 24622029>> BeforeRun: getFocus() 553486624 ||| getCurrentModule() 553486624
<<pool-1-thread-14, 12115695>> BeforeRun: getFocus() 553486625 ||| getCurrentModule() 553486625
<<pool-1-thread-8, 18751079>> BeforeRun: getFocus() 553486626 ||| getCurrentModule() 553486624

The problem thread is 'pool-1-thread-8'. The focus seems to be thread safe.

Ernest has mentioned in his answer that the current module is not designed to be unique to each thread in a peer scenario. So I would like to go on with the discussion in reply to his answer.

Thx,
Ralf


-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Wolfgang Laun
Gesendet: Dienstag, 19. April 2011 19:04
An: [hidden email]
Betreff: Re: JESS: Wrong results if using modules and peers in a multithreaded context

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 <[hidden email]> 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: '[hidden email]'
> 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: [hidden email]
>
> 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 [hidden email]'
> in the BODY of a message to [hidden email], NOT to the list
> (use your own address!) List problems? Notify [hidden email]




--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

AW: JESS: Wrong results if using modules and peers in a multithreaded context

Grube, Ralf
In reply to this post by Friedman-Hill, Ernest
Thank you for your answer. It makes a lot of sense, but can you help me finding the conceptional flaw with us?!

The rulebase is not changed after we create the peers.
But as you can see in the logs we add our facts into the currently selected module. Facts are "new constructs" as well, aren't they. And they have to be provided during runtime (so after the peers are created).
And that seems to be the problem. The facts are added into the wrong module. This is why no rule is activated. Even if they would be activated in the "wrong" module they could never fire, because the module does not have the focus (see log in answer to Wolfgangs reply).



-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Ernest Friedman-Hill
Gesendet: Dienstag, 19. April 2011 20:47
An: jess-users
Betreff: Re: JESS: Wrong results if using modules and peers in a multithreaded context

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: '[hidden email]'
> 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: [hidden email]
>
> 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  
> [hidden email]'
> in the BODY of a message to [hidden email], NOT to the list
> (use your own address!) List problems? Notify [hidden email]
> .
> --------------------------------------------------------------------

---------------------------------------------------------
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 [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------





--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------