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: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] Im 
Auftrag von Wolfgang Laun
Gesendet: Dienstag, 19. April 2011 19:04
An: jess-users@sandia.gov
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 <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




--------------------------------------------------------------------
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.
--------------------------------------------------------------------

Reply via email to