Opsss. Sorry ... my mistake
The phrase:
"I did use sync on any reference ..."
should b:
"I did not use sync on any reference ..."Dotan
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: [rules-dev] Multi threading
usage best practiceDate: Mon, 14 Jul 2008 17:53:59 +0300
I did use sync on any reference 2 the working memory with the hope of archiving
the maximum performance from Drools.Stateless session seems like a waste of
resources when thinking of the volume of messages passing through the server
and translating that 2 create and destroy a session per each one.MayB i should
rephrase my rules in some way that they would know if the message was already
processed? Dotan
Subject: RE: [rules-dev] Multi threading usage best practiceDate: Mon, 14 Jul
2008 14:51:49 +0100From: [EMAIL PROTECTED]: [email protected]
Did you synchronise on the insertion of objects into working memory too? (not
as part of an activation on the RHS).
What about the use of a stateless session per thread (isn't session creation
really quick once the package\rulebase has been compiled)? In the mail relay
below won't you want the set of rules to apply to one set of facts inserted by
one thread representing one message? Is this achievable with a shared working
memory? (Could you not get an activation caused by the presence of a fact
inserted into working memory by one thread and the insertion into the same
working memory of a fact by another thread).
This is much more interesting that work ;-)
Mike
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fenderbosch,
EricSent: 14 July 2008 14:36To: Rules Dev ListSubject: RE: [rules-dev] Multi
threading usage best practice
We have multiple threads performing inserts/updates/queries/fireAllRules and
had to synchronize access on working memory. The performance impact is
surprisingly almost non-existent.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anstis, Michael
(M.)Sent: Monday, July 14, 2008 9:24 AMTo: Rules Dev ListSubject: RE:
[rules-dev] Multi threading usage best practice
Hi,
Would synchronising on working memory effectively serialise the effects of
fireAllRules()?
...
synchronised(wm) {
wm.fireAllRules();
}
...
I don't know whether this would kill your through-put either.
Cheers,
Mike
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 9Lives
9LivesSent: 14 July 2008 13:41To: [EMAIL PROTECTED]: [rules-dev] Multi
threading usage best practice
Hello I'm using Drools 4.0.7 inside a mail relay application 2 determine the
operations that need 2 b executed on each passing message.To do this i'm using
the following scenario:
I have a ruleBase.newStatefulSession().
I have a fixed set of facts.
I have a fixed set of rules.
Each mailer (a thread that is handling a single message) is inserting the
message to the working memory, calls the "fireAllRules" method and retracts the
message.
Rules that r executed change custom attributes in the message.Problem:I noticed
that sometimes a rule can b executed on the same message more then once.
Assumption:My guess is that because i'm working is a multi threading
environment but using a stateful session, what happens is:
Thread A is inserting Message A.
Thread B is inserting Message B
Thread A is calling fireAllRules
Rule X is executed on messages A + B.
Thread B is calling fireAllRules
Rule X is executed on messages A + B
Thread A is retracting Message A
Thread B is retracting message BQuestion:My goal is 2 make sure a rule is
executed only once on a single message.Any ideas on how 2 avoid the situation
described above? TnXDotan
Invite your mail contacts to join your friends list with Windows Live Spaces.
It's easy! Try it!
Connect to the next generation of MSN Messenger Get it now!
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces.
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
