Problem setting Sequential for kbase Drools 5.1.1
by pjeynes
Hi, I have some rules that require stateless sequential execution. I
initially created a knowledge base manually in code and using the following
approach, the rules run sequentially:
KnowledgeBaseConfiguration config =
KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
config.setOption(SequentialOption.YES);
kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
I then converted my manual knowledge base generation into a Spring bean and
now I can't seem to set the knowledge base as sequential. The rules run as
rete.
<!-- Bean for Drools rules engine instance (aka KnowledgeBase) -- >
<drools:kbase id="rules-engine">
<drools:resources>
<drools:resource ref="serialisation-rules-resource-1"/>
</drools:resources>
<drools:configuration>
<drools:mbeans enabled="true" />
<drools:event-processing-mode mode="STREAM" />
</drools:configuration>
</drools:kbase>
Googling for clues, I also tried setting drools.sequential to true in
rulebase.conf. I placed this file in the classpath but again, the rules run
as rete rather than sequential.
How can I get the rules to run sequentially when the rule base is created
via Spring? I scanned down the drools spring XSD and couldn't see any
config param that could be added within the drools:configuration section
either.
Cheers.
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Problem-setting-Seque...
Sent from the Drools - Dev mailing list archive at Nabble.com.
13 years, 6 months
unknown error while parsing
by Boschung Daniel
hi folks
drools prompt me to contact the development team. the following error apears, whithout stacktrace, while developing
a rule. maybe the error is known to you?!
thanks for a little statement
daniel
13 years, 6 months
Dead pipeline?
by Wolfgang Laun
drools-api.jar in a few 5.1.0 versions still contains
org.drools.runtime.pipeline, but the 5.1.1. drools-api.jar doesn't any more,
and neither does any of the other jars in the download.
So where is this package?
-W
13 years, 6 months
query examples
by DDUGGAN
Can someone point me in the direction of examples using queries?? I have a
simple query and rule that I cannot get operational.
query "IKnow"
oRecord : MyRecord( status == "IKnow" )
end
rule "Print My Records"
no-loop true
dialect "java"
QueryResults $Results = ksession.getQueryResults( "IKnow" ); **
System.out.println( "We have " + results.size( ) + " Records" );
for ( QueryResultsRow row : results )
**
{
MyRecord $oRecord = ( MyRecord ) row.get( "oRecord" ); **
System.out.println( $oRecord.toString() + "\n" );
}
end
** - I get no viable alternative at input on these 3 lines. Usually missing
) or " but I don't see an issue.
Thanks!
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/query-examples-tp1787...
Sent from the Drools - Dev mailing list archive at Nabble.com.
13 years, 6 months
[vote] Module drools-atom in limbo
by Geoffrey De Smet
I am looking at cleaning up the build and moving to maven 3, to make it
faster, more reliable, etc.
I am also actively wondering if some modules or files aren't dead code.
First candidate is drools-atom:
The module drools-atom is in limbo:
- It still exists
- It's not part of any build
- Does it still build? No
-- 'dependencies.dependency.version' is missing for
org.apache.cxf:cxf-rt-frontend-jaxrs:jar
- Does it still compile against the latest drools version? Idunno, but
since it's not part of the build, tomorrow's refactor might break it.
- Does anyone use it? If it doesn't build and it isn't released... no?
I don't think that code is useful to anyone in this state. I do think
it's presence alone slightly complicates the drools sources.
What do we do with it?
- [A] remove the directory drools-atom from trunk (it's still retired in
in subversion)
- [B] leave it like it is now. It might be usefull to someone
- [C] add it to the build again, make it work
- [D] create a separate repository "drools-incubator" and move it there
In my opinion:
+1 for [A]
-1 for [B]: either it builds or it's not in trunk
If we all agree that removing dead modules is a good idea, I 'll provide
a list of possible candidates next time.
--
With kind regards,
Geoffrey De Smet
13 years, 6 months
drools-guvnor jiras are moved from JBRULES to GUVNOR
by Toni Rikkola
Hi,
>From now on there is only one location for Jiras related to Guvnor. JBRULES/drools-guvnor is being removed and the Jira issues are moved to GUVNOR [1].
I also wanted to warn and apologize you about the Jira spam some of you will soon get. Jira sends emails about the move to everybody following the issues.
[1] https://jira.jboss.org/browse/GUVNOR
(Of course this warning is not helping you if your an Assignee or Reporter on most of them and happen to be living in, lets say Australia. Then you might just wake up and find this and 300 other emails in your mailbox.)
Toni Rikkola
13 years, 6 months
Re: [rules-dev] [rules-users] Starting engine using fireUntilHalt and inserting no facts results in 50% CPU usage
by Greg Barton
Yep. :) I always propose minimal change solutions first, but having the single flag is best in this case.
GreG
On Oct 26, 2010, at 10:22, Edson Tirelli <tirelli(a)post.com> wrote:
Hi Greg,
Thanks for the excellent analysis and the help. I agree with your findings.
For a solution though, I was thinking about just completely undoing
30163 (i.e., removing that missedNotifyAll flag as I think it just
complicates things) and simply adding a halt check inside the
synchronized block that calls the wait:
synchronized ( this.halt ) {
if( !this.halt.get() ) this.halt.wait();
}
Since the notify only happens on a synchronized block, I think that
this fixes the problem as it creates a happens-before relationship
between setting the halt flag and ( notifying all threads on the halt
monitor || checking the flag and executing the wait ).
Let me know what you think.
JIRA: https://jira.jboss.org/browse/JBRULES-2756
Changeset: http://fisheye.jboss.org/changelog/JBossRules/?cs=35744
Thanks,
Edson
2010/10/26 Greg Barton <greg_barton(a)yahoo.com>:
Here's a diff for the minimal change I think fixes the problem:
Index: src/main/java/org/drools/common/DefaultAgenda.java
===================================================================
--- src/main/java/org/drools/common/DefaultAgenda.java (revision 35727)
+++ src/main/java/org/drools/common/DefaultAgenda.java (working copy)
@@ -1048,10 +1048,10 @@
boolean fired = fireNextItem( agendaFilter );
fired = fired || !((AbstractWorkingMemory) this.workingMemory).getActionQueue().isEmpty();
this.workingMemory.executeQueuedActions();
- if ( !fired && !missedNotifyAll.get()) {
+ if ( !fired ) {
try {
synchronized ( this.halt ) {
- this.halt.wait();
+ if(!missedNotifyAll.get()) this.halt.wait();
}
} catch ( InterruptedException e ) {
this.halt.set( true );
Basically, move the missedNotifyAll check immediately before the wait. This still avoids the race condition, and only causes one spurious trip through the fireUntilHalt loop on startup. I'd open a JIRA with this in it but I need to get to sleep. :)
--- On Tue, 10/26/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>, rules-dev(a)lists.jboss.org
Date: Tuesday, October 26, 2010, 1:01 AM
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
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
13 years, 6 months
FAO: conan: ClassCastException with from and subtypes...
by Michael Anstis
Hi Mark,
This is the gist of the IRC discussion (raised by nik9000) you was asking
about.
I tried with a new download from trunk and the CCE remains:-
class Taggable {}
class Asset extends Taggable {}
class TagDataReceivedEvent {
private final Taggable taggable;
public Taggable getTaggable() { return taggable; }
}
rule "f"
when
$e: TagDataReceivedEvent(newLocation != oldLocation)
$a: Asset() from $e.taggable
then
System.err.println("ASF" + $a);
end
ClassCastException thrown on the "from" - you thought this might have been
changed to fail (I took to mean as "not match" rather than a RTE failue).
Cheers,
Mike
13 years, 6 months
