Re: [rules-users] Starting engine using fireUntilHalt and inserting no facts results in 50% CPU usage
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-boun...@lists.jboss.org
[mailto:rules-users-boun...@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 :
> 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-boun...@lists.jboss.org
> [mailto:rules-users-boun...@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 :
>>
>>
>> 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, 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>>
>> ___
>> rules-users mailing list
>> rules-users@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> ___
> rules-users mailing list
> rules-users@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Starting engine using fireUntilHalt and inserting no facts results in 50% CPU usage
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-boun...@lists.jboss.org
[mailto:rules-users-boun...@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 :
>
>
> 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, 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> ___
> rules-users mailing list
> rules-users@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() and OSGi - CPU load
"When invoking fireUntilHalt() for my StatefulKnowledgeSession, CPU load
rises to 25% (meaning one complete core on the quad-core machine)."
I can confirm this issue. Below is a minimal example. I have noticed that in
DefaultAgenda, missedNotifyAll is always true in this case, is this an
intended behaviour?
http://www.jboss.org/drools";
typeLanguage="http://www.java.com/javaTypes";
expressionLanguage="http://www.mvel.org/2.0";
xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL";
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance";
xs:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL
BPMN20.xsd"
xmlns:g="http://www.jboss.org/drools/flow/gpd";
xmlns:tns="http://www.jboss.org/drools";>
john
public void test() throws InterruptedException{
try {
// load up the knowledge base
KnowledgeBase kbase = readKnowledgeBase();
final StatefulKnowledgeSession ksession =
kbase.newStatefulKnowledgeSession();
WSHumanTaskHandler wsh = new WSHumanTaskHandler();
wsh.setConnection("127.0.0.1", 9123);
ksession.getWorkItemManager().registerWorkItemHandler("Human Task", wsh);
new Thread(new Runnable() {
public void run() {
ksession.fireUntilHalt();
}
}).start();
ksession.startProcess("servicerequest2");
} catch (Throwable t) {
t.printStackTrace();
}
Thread.sleep(120);
}
private static KnowledgeBase readKnowledgeBase() throws Exception {
KnowledgeBuilder kbuilder =
KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(ResourceFactory.newClassPathResource("testcases/integrationuc/servicerequest.bpmn"),
ResourceType.BPMN2);
return kbuilder.newKnowledgeBase();
}
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/fireUntilHalt-and-OSGi-CPU-load-tp1022352p1131701.html
Sent from the Drools - User mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Unit test for Ad-Hoc Task / Ad-Hoc Subprocess
Hi there (->Kris), for the unit test testAdHocSubProcess() in trunk, shouldn't there be added at the end: assertProcessInstanceCompleted(processInstance.getId(), ksession); , which would fail. Either this is an error or I haven't properly understood a concept of the ad-hoc subprocess. Can you give me a hint? Thanks & Cheers Markus ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] CEP Demo Code
Hi, is the code resp. rules and flow definitions for the CEP examples posted by Krisv (http://blog.athico.com/2009/08/drools-flow-videos.html; e.g. http://downloads.jboss.com/drools/videos/OrderExample-CEP.swf) available somewhre? I can't find it in the examples package. thanks and best, Markus ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] BaseMinaClient - Session Termination
Hello,
I have a simple RuleFlow containing a Human Task, which I start using the
following lines of code:
WSHumanTaskHandler wsh = new WSHumanTaskHandler();
ksession.getWorkItemManager().registerWorkItemHandler("Human Task", wsh);
ksession.startProcess("com.sample.ruleflow");
When the workflow has properly ended however, there remain threads (e.g.
NioProcessor&NioSocketConnector) within the VM. I have tracked this down to
BaseMinaClient:
public void disconnect() {
if ( session!= null && session.isConnected() ) {
session.close();
session.getCloseFuture().join();
}
}
Expllicitly calling wsh.dispose(), session.isConnected() (from IoSession)
always yields true even when the workflow instance has terminated already
and there are no more active human tasks available.
Is this an intended behaviour?
Thanks and best
Markus
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Error trying to build Drools 5.0 from source
*(This should be also valid for 5.1, I just want to keep the relation to previous postings on this issue)* In case anyone encounters similar obstacles: I have used newer versions of ANT and MAVEN for building Drools 5.1 from trunk. Using the exact versions as shown below did not yield the cyclic reference / stack overflow type of error. Additionally I ran into a number of test problems during build related to my locale (Germany) and date formatting. As an intermediary result, the following settings helped preventing some (but not all) build problems: set path=C:\Program Files\Java\jdk1.5.0_08\bin;C:\droolsinst\apache-maven-2.0.9-bin\bin;C:\drool sinst\apache-ant-1.7.0-bin\bin set MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m -Duser.country=EN -Duser.language=en set JAVA_HOME=C:\Program Files\Java\jdk1.5.0_08 set MAVEN_HOME=C:\droolsinst\apache-maven-2.0.9-bin\bin set ANT_HOME=C:\droolsinst\apache-ant-1.7.0-bin\bin set ANT_OPTS=-Duser.country=EN -Duser.language=en Best Markus _ Von: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] Im Auftrag von mardo Gesendet: Dienstag, 3. November 2009 20:15 An: rules-users@lists.jboss.org Betreff: Re: [rules-users] Error trying to build Drools 5.0 from source Hi, similar as <http://lists.jboss.org/pipermail/rules-users/2009-October/010742.html> http://lists.jboss.org/pipermail/rules-users/2009-October/010742.html, I have Maven build problems for Drools 5.1 - "The projects in the reactor contain a cyclic reference ." when including -Ddocumentation in the Maven parameters - java.lang.StackOverflowError when excluding "-Ddocumentation" I tried both setting Java (home and path) to jdk1.5.0_19 and jdk1.6.0_10 My MAVEN_OPTS are set to "-XX:MaxPermSize=256m -Xmx1224m -Xss20m" Do you have any suggestions? Thanks and best Markus ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Test Failure: RioRemoteTest
I am executing "mvn -Ddocumentation -Declipse clean install" on the current sources in SVN, with the following reoccurring result: Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.324 sec Results : Tests in error: testFireAllRules(org.drools.vsm.ServiceManagerRioRemoteTest) testExecute(org.drools.vsm.ServiceManagerRioRemoteTest) testNamedService(org.drools.vsm.ServiceManagerRioRemoteTest) testVsmPipeline(org.drools.vsm.ServiceManagerRioRemoteTest) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to C:\droolsinst\Drollig\drools-vsm\target\surefire-reports for the individual test results. Looking in surefire reports at the concerned location, I have java.lang.NullPointerException at org.drools.vsm.ServiceManagerRioRemoteTest.setUp(ServiceManagerRioRemoteTest .java:21) Which in turn corresponds to the LoC GenericMessageHandler handler = ((SessionServiceImpl)rioServer.getSessionService()).getGenericMessageHandler (); Do you have any suggestions on how to prevent this error? Thanks alot, Markus ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Error trying to build Drools 5.0 from source
Hi, similar as http://lists.jboss.org/pipermail/rules-users/2009-October/010742.html, I have Maven build problems for Drools 5.1 - "The projects in the reactor contain a cyclic reference ." when including -Ddocumentation in the Maven parameters - java.lang.StackOverflowError when excluding "-Ddocumentation" I tried both setting Java (home and path) to jdk1.5.0_19 and jdk1.6.0_10 My MAVEN_OPTS are set to "-XX:MaxPermSize=256m -Xmx1224m -Xss20m" Do you have any suggestions? Thanks and best Markus ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Blocking Call to startProcess()
Kris, thanks for the quick reply. It makes perfect sense what you're saying about the implementation issues on the task level. Did I get it right that e.g. a specific task for (asynchronous) web service invocation would be implemented very similar to the WorkItemHandler http://www.mail-archive.com/rules-users@lists.jboss.org/msg09450.html? I didn't however understand yet why startProcess() has to block at all. Naively, this would rather be the semantics of a method like "executeProcess()". From my current understanding, even when launching concurrent instances from different threads using startProcess(), the required return value (ProcessInstance) I was aiming at is obtained earliest at the first wait state or termination of the process, right? Thanks so far! Best Markus -Ursprüngliche Nachricht- Von: Kris Verlaenen [mailto:kris.verlae...@cs.kuleuven.be] Gesendet: Dienstag, 3. November 2009 16:11 An: Rules Users List; mardo Betreff: Re: [rules-users] Blocking Call to startProcess() Markus, You should not block the execution thread using long-running tasks (like sleep()) in actions, as this will actively lock the resources of the engine. You should use wait states, event nodes and/or work item nodes if you want to perform long-running tasks. Even when implementing a work item handler, the work performed there should either be quick and synchronous or performed asynchronously (acting as a wait state). As a result, startProcess() will block only until the process has reached a wait state, but this should almost be instantaneously (and if you don't have any asynchronous behaviour, this could already be the completion of your process). This allows concurrent execution of process instances if they contain asynchronous tasks (which is usually sufficient). You could also invoke the engine non-blocking (in a separate thread) if you want true concurrency. Kris Quoting mardo : > > > Hi there, > > > > I just began exploring the capabilities of drools and also > considered its > > applicability for typical EAI scenarios. > > > > It really may be a beginner's question. But I took the simple > example > > workflow and inserted a Thread.sleep() for its task action. > > > > I experienced the blocking startProcess() as discussed here: > > > > > http://stackoverflow.com/questions/1326718/how-to-start-multiple-processes > > -in-drools-flow > > > > So did I miss something or how would it be possible to get the > internal ID > > of the WF instance right after starting it before its completion to > be > > able to query the engine proactively during runtime? > > > > I also see that this relates to > > > http://www.mail-archive.com/rules-users@lists.jboss.org/msg05828.html, > but > > I also don't see a solution here. > > > > > > > > Thanks and Best > > > > > > Markus > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Blocking Call to startProcess()
> Hi there, > > I just began exploring the capabilities of drools and also considered its > applicability for typical EAI scenarios. > > It really may be a beginner's question. But I took the simple example > workflow and inserted a Thread.sleep() for its task action. > > I experienced the blocking startProcess() as discussed here: > > http://stackoverflow.com/questions/1326718/how-to-start-multiple-processes > -in-drools-flow > > So did I miss something or how would it be possible to get the internal ID > of the WF instance right after starting it before its completion to be > able to query the engine proactively during runtime? > > I also see that this relates to > http://www.mail-archive.com/rules-users@lists.jboss.org/msg05828.html, but > I also don't see a solution here. > > > > Thanks and Best > > > Markus ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
