The problem is the race condition fix introduced in rev 30163. The missedNotifyAll flag
is set to true immediately which causes the busy loop.
missedNotifyAll is initialized to false, but is immediately set to true because
notifyHalt() is called in AbstractWorkingMemory.queueWorkingMemoryAction() via
ReteooRuleBase.newStatefulSession(). Anyway, I'll move discussions of possible
solutions over to the dev list, (crossposting now) or a JIRA if you'd prefer that.
--- On Mon, 10/25/10, Greg Barton <greg_barton(a)yahoo.com> wrote:
From: Greg Barton <greg_barton(a)yahoo.com>
Subject: Re: [rules-users] Starting engine using fireUntilHalt and inserting no facts
results in 50% CPU usage
To: "Rules Users List" <rules-users(a)lists.jboss.org>
Date: Monday, October 25, 2010, 3:18 PM
I was going to look at this at some
point. I guess that point will be tonight. :)
GreG
On Oct 25, 2010, at 15:02, Edson Tirelli <tirelli(a)post.com>
wrote:
No worries, it is a good starting point anyway.
Hopefully someone
can continue from there or I will eventually fix it. Just a
lot of
stuff in my plate already that have priority over this.
Edson
2010/10/25 mardo <mardo(a)abicola.de>:
Unfortunately no, I just had a look how it was implemented
(like
http://tutorials.jenkov.com/java-concurrency/thread-signaling.html#missedsig
nals) -> missed signals and noticed that it somehow
didn't work as intended.
But no idea how to directly correct it, sorry.
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org]
On Behalf Of Edson Tirelli
Sent: Montag, 25. Oktober 2010 21:30
To: Rules Users List
Subject: Re: [rules-users] Starting engine using
fireUntilHalt and inserting
no facts results in 50% CPU usage
Do you have a solution/patch for it?
Edson
2010/10/25 mardo <mardo(a)abicola.de>:
Luckily just stumbled upon this mail...
You can take a look at
http://drools-java-rules-engine.46999.n3.nabble.com/fireUntilHalt-and-OSGi-C
PU-load-td1022352.html
where I already provided a minimal example (don't know if
it covers all
cases) and tracked it down to missedNotifyAll in
DefaultAgenda
cheers
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org]
On Behalf Of Edson Tirelli
Sent: Montag, 25. Oktober 2010 21:17
To: Rules Users List
Subject: Re: [rules-users] Starting engine using
fireUntilHalt and
inserting
no facts results in 50% CPU usage
This is clearly a regression as Drools should be not be
using busy
waits in fireUntilHalt(). It should use monitors and locks
as it was
doing before.
Can anyone open a JIRA? also, if anyone would be willing
to take
investigate and fix this one, it would really help.
Otherwise, I will
add it to my queue.
Thanks,
Edson
2010/10/25 Norman C <rent_my_time(a)yahoo.com>:
Note that the 100% CPU issue with fireUntiHalt is only with
the 5.1
version of
Drools. In 5.0.x, CPU is close to 0% when there are
no rules to fire. I
saw
this when I was testing upgrading to 5.1.
Norman
----- Original Message ----
From: jschmied <nabble(a)juergenschmied.de>
To: rules-users(a)lists.jboss.org
Sent: Sun, October 24, 2010 4:06:02 AM
Subject: Re: [rules-users] Starting engine using
fireUntilHalt and
inserting no
facts results in 50% CPU usage
Hi!
fireUntilHalt uses one processor with 100%. You have a
dualcore, so it's
50%. It's by design like this.
You can:
- Call fireAllRules after every insert if you have no
ruleflow.
- Use fireAllRules in a loop with a small sleep and check
for the end of
the
ruleflow in the loop:
while (prc.getState() == ProcessInstance.STATE_ACTIVE) {
Threads.sleep(20);
ksession.fireAllRules();
}
with both methods you get a low cpu load.
bye
juergen
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Starting-engine-using-fi
reUntilHalt-and-inserting-no-facts-results-in-50-CPU-usage-tp1760370p1761821
.html
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users