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