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: [email protected] [mailto:[email protected]] 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: '[email protected]' > 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: [email protected] > > 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 > [email protected]' > in the BODY of a message to [email protected], NOT to the list > (use your own address!) List problems? Notify [email protected] > . > -------------------------------------------------------------------- --------------------------------------------------------- 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 [email protected]' in the BODY of a message to [email protected], NOT to the list (use your own address!) List problems? Notify [email protected]. -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [email protected]' in the BODY of a message to [email protected], NOT to the list (use your own address!) List problems? Notify [email protected]. --------------------------------------------------------------------
