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
To: rules-users@lists.jboss.org
Sent: Sun
Drools can deadlock when facts are inserted/retracted/modified in multiple
entry
points in the same session. Since each such action will acquire the lock
associated with the entry point, it's possible for the order of calls to cause
deadlock when the locks for two entry points are acquired by
Sent: Tue, October 5, 2010 11:34:53 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
Norman,
if you create the Jira, please include my suggestion to make this call accept a
collection of facts without any intervening Engine activity.
Thanks
-W
2010/10/5 Norman C
>
ou're using it as opposed to just
calling fireAllRules?
GreG
On Oct 5, 2010, at 16:34, Norman C wrote:
>
>Thanks for the suggestions. They all look like good ways to handle the
>situation I described. However, they require modifying all of the rules to
>check for the latc
d of using
fireUntilHalt(), you call fireAllRules() in a loop, either after each
X insertions of every Y seconds, depending on your system's
architecture.
Edson
2010/10/5 Norman C :
>
> Thanks for the suggestions. They all look like good ways to handle the
> situation I described
a : A( latch == l )
>
> then
>
> retract(a);
>
> l.incACount();
>
> System.out.println("Found an A in " + bl);
>
>end
>
>
>
>Note that the A object being processed is tied back to the l
Hi All,
In my app, I have a separate thread calling fireUntilHalt() continuously. I
have quite a few rules, and I am using salience extensively to control the
order
in which rules are executed. What I have seen (by adding an event listener) is
that as a new fact is inserted, various rules a
Mark,
Thanks for your help. I will apply this fix in my production system.
Norman
On 18/08/2010 00:49, Norman C wrote:
>Hi All,
>I've posted on this topic twice and logged a JIRA ticket
>(https://jira.jboss.org/browse/JBRULES-2651) as well. I've received
>no respon
r your help.
Norman
________
From: Norman C
To: rules-users@lists.jboss.org
Sent: Wed, August 4, 2010 11:23:55 PM
Subject: Re: Possible concurrency issue in Drools
I've run into this issue a few more times. Should I log a JIRA ticket for
this? Any advice would be app
I've run into this issue a few more times. Should I log a JIRA ticket for
this? Any advice would be appreciated.
Thanks,
Norman
From: Norman C
To: rules-users@lists.jboss.org
Sent: Sat, July 31, 2010 9:56:26 PM
Subject: Re: Possible concurrency iss
All,
Just wanted to mention, I'm using version 5.0.1 of Drools.
Thanks,
Norman
From: Norman C
To: rules-users@lists.jboss.org
Sent: Sat, July 31, 2010 9:50:19 PM
Subject: Possible concurrency issue in Drools
Hi All,
I recently ran into an issue
Hi All,
I recently ran into an issue which I believe might point to a concurrency
issue. My server stopped processing new requests, so I did a thread dump. In
examining the dump, I found that all of the processing threads, save two, were
blocking while trying to acquire the lock in NamedEnt
Hi All,
I'm working with Drools Fusion and have run into the deadlock issue in
https://jira.jboss.org/browse/JBRULES-2375 (Drools hangs when events are
retracted). This bug indicates it is fixed in 5.1.0.CR1. How can I get this
fix, or alternatively, where in the SVN repository can I look a
13 matches
Mail list logo
