RE: [rules-users] Not Non-Existential Quantifier
How is your rule base configured, with identity or equality assert behavior? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 04, 2008 9:59 AM To: Rules Users List Subject: Re: [rules-users] Not Non-Existential Quantifier Edson, I finally succeeded in coming up with a simple test case that shows the problem. I have attached the necessary files, which include a test case, three fact objects, and the drl. One key to this test are the fact that the Applicant fact object has an equals method that tests for equality of its attributes, rather than identity. A second key is that the applicant object is updated after it is inserted. It appears that what is happening is that an activation is created for the rule that uses not when the applicant is inserted. Then, when the applicant is updated, a second activation is created for that rule. It should be cancelling the previous activation, but doesn't find it because the Applicant instance no longer equals the fact object that caused the activation. Thanks! -Hans -- Original message -- From: Edson Tirelli [EMAIL PROTECTED] Hans, Your reasoning is correct. There should not be 2 instances of ApplicantStatus in the working memory. Can you provide a test case showing the problem? we have test cases here using not and logical assertions, and it works properly. Thanks, Edson 2008/7/31 [EMAIL PROTECTED] How is not supposed to work with insertLogical? Assume I have two different rules whose conditions are mutually exclusive, like the following: rule Rule One when not NegativeResult() then insertLogical(new ApplicantStatus(Approved)); end rule Rule Two when NegativeResult() then insertLogical(new ApplicantStatus(Denied)); end Assume that the above two rules are the only way an ApplicantStatus fact can be inserted into working memory. I would expect, after all rules are run, that it would be impossible for there to be one ApplicantStatus with Approved as its reason, and another with Denied as its reason, in the working memory. I would expect that, before any NegativeResult is inserted, that rule one could run, and insert an ApplicantStatus fact with an Approved reason. Then, after a NegativeResult is inserted, that rule two could run, and insert an ApplicantStatus fact with a Denied reason. At this point I would expect that the original ApplicantStatus fact, with an Approved reason, would be retracted, since the conditions under which it was inserted are no lon! ger true. This is not what I am observing, however. I am finding ApplicantStatus facts with both reasons in working memory at the end of the rules run. Should not work as I expect with regard to inserting a fact via insertLogical()? Or is this a known limitation, or simply the way it is designed to work? Thanks, -Hans ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss, a division of Red Hat @ www.jboss.com http://www.jboss.com/ ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] Design Question (hashCode/equals/fact maintenance)
I just realized I could use the from CE to avoid this entire mess.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fenderbosch,
Eric
Sent: Tuesday, July 15, 2008 10:38 AM
To: rules-users@lists.jboss.org
Subject: [rules-users] Design Question (hashCode/equals/fact
maintenance)
I'm just looking for a bit of verification that this is a reasonable
solution. This just feels like a hack and there's probably a better way
that I'm just not seeing. Alternate ideas are welcome and appreciated.
Thanks in advance.
The objective is to find the best workers for a job:
Jobs have a location.
Workers have a location.
Scores are calculated based on miles and minutes of a route from the
worker to a job.
When a job or worker location changes, then the route should be
recalculated so that scores can be recalculated. It is possible for a
location to get re-inserted that might be the functionally the same as a
previous location for a job/worker, but a different instance. In this
case, the route should not be recalculated and the old scores should
remain.
assert behavior = equality
logical override = discard
maintain tms = true
remove identies = true
shadow proxies are enabled
public class JobLatitudeLongitude {
private String jobId;
private double latitude;
private double longitude;
private long timestamp = System.currentTimeMillis();
// getters setters omitted for brevity
public int hashCode() {
return jobId.hashCode();
}
public boolean equals(Object obj) {
// not null or type safe, just simple version for
brevity
JobLatitudeLongitude other = (JobLatitudeLongitude) obj;
return this.jobId.equals(other.jobId) this.timestamp
== other.timestamp;
// would return false; work ???
}
}
rule retract redundant job latitude/longitude facts
// if more than one lat/long with same position for a job, keep the
oldest
salience 600
when
older : JobLatitudeLongitude()
newer : JobLatitudeLongitude(jobId == older.jobId,
latitude == older.latitude, longitude == older.longitude, timestamp =
older.timestamp)
then
retract(newer);
end
rule retract old job latitude/longitude facts
// if more than one lat/long with different position for a job, keep the
newest
salience 600
when
older : JobLatitudeLongitude()
newer : JobLatitudeLongitude(jobId == older.jobId,
latitude != older.latitude, longitude != older.longitude, timestamp =
older.timestamp)
then
retract(older);
end
rule add Route fact
salience 450
when
jobLatitudeLongitude : JobLatitudeLongitude()
workerLatitudeLongitude : WorkerLatitudeLongitude()
then
// calculateRoute is an imported function
Route route = calculateRoute(workerLatitudeLongitude,
jobLatitudeLongitude);
insertLogical(route);
end
___
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
[rules-users] Design Question (hashCode/equals/fact maintenance)
I'm just looking for a bit of verification that this is a reasonable
solution. This just feels like a hack and there's probably a better way
that I'm just not seeing. Alternate ideas are welcome and appreciated.
Thanks in advance.
The objective is to find the best workers for a job:
Jobs have a location.
Workers have a location.
Scores are calculated based on miles and minutes of a route from the
worker to a job.
When a job or worker location changes, then the route should be
recalculated so that scores can be recalculated. It is possible for a
location to get re-inserted that might be the functionally the same as a
previous location for a job/worker, but a different instance. In this
case, the route should not be recalculated and the old scores should
remain.
assert behavior = equality
logical override = discard
maintain tms = true
remove identies = true
shadow proxies are enabled
public class JobLatitudeLongitude {
private String jobId;
private double latitude;
private double longitude;
private long timestamp = System.currentTimeMillis();
// getters setters omitted for brevity
public int hashCode() {
return jobId.hashCode();
}
public boolean equals(Object obj) {
// not null or type safe, just simple version for
brevity
JobLatitudeLongitude other = (JobLatitudeLongitude) obj;
return this.jobId.equals(other.jobId) this.timestamp
== other.timestamp;
// would return false; work ???
}
}
rule retract redundant job latitude/longitude facts
// if more than one lat/long with same position for a job, keep the
oldest
salience 600
when
older : JobLatitudeLongitude()
newer : JobLatitudeLongitude(jobId == older.jobId,
latitude == older.latitude, longitude == older.longitude, timestamp =
older.timestamp)
then
retract(newer);
end
rule retract old job latitude/longitude facts
// if more than one lat/long with different position for a job, keep the
newest
salience 600
when
older : JobLatitudeLongitude()
newer : JobLatitudeLongitude(jobId == older.jobId,
latitude != older.latitude, longitude != older.longitude, timestamp =
older.timestamp)
then
retract(older);
end
rule add Route fact
salience 450
when
jobLatitudeLongitude : JobLatitudeLongitude()
workerLatitudeLongitude : WorkerLatitudeLongitude()
then
// calculateRoute is an imported function
Route route = calculateRoute(workerLatitudeLongitude,
jobLatitudeLongitude);
insertLogical(route);
end
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] Drools 4 poor performance scaling?
FYI for the group. We seem to have solved our performance problem.
I'll describe our problem space a bit some people have some context. We
load up about 1200 Jobs with about 3000 Stops and about 1500 Vehicles
with about 2000 Workers. We then calculate Scores for each Vehicle for
each Job. Some combinations get excluded for various reasons, but we
end up with 700k - 900k total facts. We do score totaling and sorting
using accumulators.
One of our teams members (nice find Dan) decided to try to isolate the
accumulation rules until all our other facts are loaded. Those rules
now have a not ColdStarting() condition and our startup code inserts a
ColdStarting fact as the first fact and retracts it when all the Jobs
and Workers have been loaded. This changed our startup time from over
50 minutes to under 5. There's some sort of strange propagation and
looping going on with accumulation on the fly, at least with our facts
and rules.
I'll put an entry on the wiki as well.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fenderbosch,
Eric
Sent: Monday, June 30, 2008 11:46 AM
To: Rules Users List
Subject: RE: [rules-users] Drools 4 poor performance scaling?
We are having a similar problem, although our fact count is much higher.
Performance seems pretty good and consistent until about 400k facts,
then performance degrades significantly. Part of the degradation is
from bigger and more frequent GCs, but not all of it.
Time to load first 100k facts: ~1 min
Time to load next 100k facts: ~1 min
Time to load next 100k facts: ~2 min
Time to load next 100k facts: ~4 min
This trend continues, going from 600k to 700k facts takes over 7
minutes. We're running 4.0.7 on a 4 CPU box with 12 GB, 64 bit RH Linux
and 64 bit JRockit 5. We've allocated a 9 GB heap for the VM using
large pages, so no memory paging is happening. JRockit is started w/
the -XXagressive parameter, which enables large pages and the more
efficient hash function in HashMap which was introduced in Java5 update
8.
http://e-docs.bea.com/jrockit/jrdocs/refman/optionXX.html
The end state is over 700k facts, with the possibility of nearly 1M
facts in production. After end state is reached and we issue a few GC
requests, if looks like our memory per fact is almost 9k, which seems
quite high as most of the facts are very simple. Could that be due to
our liberal use of insertLogical and TMS?
We've tried performing a commit every few hundred fact insertions by
issuing a fireAllRules periodically, and that seems to have helped
marginally.
I tried disabling shadow proxies and a few of our ~390 test cases fail
and one loops indefinitely. I'm pretty sure we could fix those, but
don't want to bother if this isn't a realistic solution.
Any thoughts?
Thanks
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ron Kneusel
Sent: Thursday, June 26, 2008 12:47 PM
To: rules-users@lists.jboss.org
Subject: [rules-users] Drools 4 poor performance scaling?
I am testing Drools 4 for our application and while sequential mode is
very fast I get very poor scaling when I increase the number of facts
for stateful or stateless sessions. I want to make sure I'm not doing
something foolish before deciding on whether or not to use Drools
because from what I am reading online it should be fast with the number
of facts I have.
The scenario: I have 1000 rules in a DRL file. They are all of the
form:
rule rule
when
Data(type == 0, value 0.185264);
Data(type == 3, value 0.198202);
then
insert(new AlarmRaised(0));
warnings.setAlarm(0, true);
end
where the ranges checked on the values and the types are randomly
generated. Then, I create a Stateful session and run in a loop timing
how long it takes the engine to fire all rules as the number of inserted
facts increases:
// Run
for(j=0; j 100; j+=5) {
if (j==0) {
nfacts = 1;
} else {
nfacts = j;
}
System.out.println(nfacts + :);
// Get a working memory
StatefulSession wm = ruleBase.newStatefulSession();
// Global - output
warnings = new Alarm();
wm.setGlobal(warnings, warnings);
// Add facts
st = (new Date()).getTime();
for(i=0; i nfacts; i++) {
wm.insert(new Data(rand.nextInt(4),
rand.nextDouble()-0.5));
}
en = (new Date()).getTime();
System.out.println(facts = + (en-st));
// Now run the rules
st = (new Date()).getTime();
wm.fireAllRules();
en = (new Date()).getTime();
System.out.println(rules = + (en-st));
// Clean up
wm.dispose();
System.out.println(\n);
}
This code is based on the HelloWorldExample.java code from
RE: [rules-users] Drools 4 poor performance scaling?
We are having a similar problem, although our fact count is much higher.
Performance seems pretty good and consistent until about 400k facts,
then performance degrades significantly. Part of the degradation is
from bigger and more frequent GCs, but not all of it.
Time to load first 100k facts: ~1 min
Time to load next 100k facts: ~1 min
Time to load next 100k facts: ~2 min
Time to load next 100k facts: ~4 min
This trend continues, going from 600k to 700k facts takes over 7
minutes. We're running 4.0.7 on a 4 CPU box with 12 GB, 64 bit RH Linux
and 64 bit JRockit 5. We've allocated a 9 GB heap for the VM using
large pages, so no memory paging is happening. JRockit is started w/
the -XXagressive parameter, which enables large pages and the more
efficient hash function in HashMap which was introduced in Java5 update
8.
http://e-docs.bea.com/jrockit/jrdocs/refman/optionXX.html
The end state is over 700k facts, with the possibility of nearly 1M
facts in production. After end state is reached and we issue a few GC
requests, if looks like our memory per fact is almost 9k, which seems
quite high as most of the facts are very simple. Could that be due to
our liberal use of insertLogical and TMS?
We've tried performing a commit every few hundred fact insertions by
issuing a fireAllRules periodically, and that seems to have helped
marginally.
I tried disabling shadow proxies and a few of our ~390 test cases fail
and one loops indefinitely. I'm pretty sure we could fix those, but
don't want to bother if this isn't a realistic solution.
Any thoughts?
Thanks
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ron Kneusel
Sent: Thursday, June 26, 2008 12:47 PM
To: rules-users@lists.jboss.org
Subject: [rules-users] Drools 4 poor performance scaling?
I am testing Drools 4 for our application and while sequential mode is
very fast I get very poor scaling when I increase the number of facts
for stateful or stateless sessions. I want to make sure I'm not doing
something foolish before deciding on whether or not to use Drools
because from what I am reading online it should be fast with the number
of facts I have.
The scenario: I have 1000 rules in a DRL file. They are all of the
form:
rule rule
when
Data(type == 0, value 0.185264);
Data(type == 3, value 0.198202);
then
insert(new AlarmRaised(0));
warnings.setAlarm(0, true);
end
where the ranges checked on the values and the types are randomly
generated. Then, I create a Stateful session and run in a loop timing
how long it takes the engine to fire all rules as the number of inserted
facts increases:
// Run
for(j=0; j 100; j+=5) {
if (j==0) {
nfacts = 1;
} else {
nfacts = j;
}
System.out.println(nfacts + :);
// Get a working memory
StatefulSession wm = ruleBase.newStatefulSession();
// Global - output
warnings = new Alarm();
wm.setGlobal(warnings, warnings);
// Add facts
st = (new Date()).getTime();
for(i=0; i nfacts; i++) {
wm.insert(new Data(rand.nextInt(4),
rand.nextDouble()-0.5));
}
en = (new Date()).getTime();
System.out.println(facts = + (en-st));
// Now run the rules
st = (new Date()).getTime();
wm.fireAllRules();
en = (new Date()).getTime();
System.out.println(rules = + (en-st));
// Clean up
wm.dispose();
System.out.println(\n);
}
This code is based on the HelloWorldExample.java code from the manual
and the setup for the rule base is the same as in the manual. As the
number of facts increases runtime increases dramatically:
facts -- runtime (ms)
10 -- 168
20 -- 166
30 -- 344
40 -- 587
50 -- 1215
60 -- 1931
70 -- 2262
80 -- 3000
90 -- 4754
with a maximum memory use of about 428 MB RAM. By contrast, if I use
sequential stateless sessions, everything runs in about 1-5 ms.
Is there something in my set up that would cause this, or is this how
one would expect Drools to scale? I read about people using thousands
of facts so I suspect I'm setting something up incorrectly.
Any help appreciated!
Ron
_
The other season of giving begins 6/24/08. Check out the i'm Talkathon.
http://www.imtalkathon.com?source=TXT_EML_WLH_SeasonOfGiving
___
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] Drools 4 poor performance scaling?
I'm in IRC now. The non-business sensitive test case hasn't been maintained. At this stage it might be pretty difficult to create one that doesn't have proprietary information and still functions anywhere the same. We've got nearly 200 rules and 20 different kinds of facts. I wonder if a simple obfuscation would be sufficient? I did give 5.0M1 a try last week. Several of our rules wouldn't compile. I tried for a day or so to fix things, but then gave up. We know it is non-optimal, but we have a few rules with if statements in the RHS and those simply wouldn't compile in 5.0. I'd like to refactor those out to at least an eval in the LHS, but ideally I'd like to precompute the statement and store the result in a new fact so that it could be indexed. Is 5.0 better for multi-threaded access as we discussed before? We've had to wrap all access to working memory in synchronized blocks when using 4.x. That's a pretty big hammer, but it works. Otherwise fact insertions/retracts, firing of rules and queries end up getting run at the same time by different threads and working memory ends up completely unusable. Maybe I'll take another stab at fixing those rules and give 5.0 another go. Any target on a 5.0 release date? We're looking to go live in production in about 1 month. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Proctor Sent: Monday, June 30, 2008 12:39 PM To: Rules Users List Subject: Re: [rules-users] Drools 4 poor performance scaling? Fenderbosch, Eric wrote: We are having a similar problem, although our fact count is much higher. Performance seems pretty good and consistent until about 400k facts, then performance degrades significantly. Part of the degradation is from bigger and more frequent GCs, but not all of it. If you have multi-cpu there is a JVM command you can set a dedicated cpu for GC, that helps somewhat. Time to load first 100k facts: ~1 min Time to load next 100k facts: ~1 min Time to load next 100k facts: ~2 min Time to load next 100k facts: ~4 min This trend continues, going from 600k to 700k facts takes over 7 minutes. We're running 4.0.7 on a 4 CPU box with 12 GB, 64 bit RH Linux and 64 bit JRockit 5. We've allocated a 9 GB heap for the VM using large pages, so no memory paging is happening. JRockit is started w/ the -XXagressive parameter, which enables large pages and the more efficient hash function in HashMap which was introduced in Java5 update 8. Other than the CPU thing, Drools won't take advantage of multipe cpus at the moment. http://e-docs.bea.com/jrockit/jrdocs/refman/optionXX.html The end state is over 700k facts, with the possibility of nearly 1M facts in production. After end state is reached and we issue a few GC requests, if looks like our memory per fact is almost 9k, which seems quite high as most of the facts are very simple. Could that be due to our liberal use of insertLogical and TMS? It could be related to this, especially if you create a long chain of logical relationships. We've tried performing a commit every few hundred fact insertions by issuing a fireAllRules periodically, and that seems to have helped marginally. I tried disabling shadow proxies and a few of our ~390 test cases fail and one loops indefinitely. I'm pretty sure we could fix those, but don't want to bother if this isn't a realistic solution. Any thoughts? Have you tried this on Drools 5.0? It 'doesn't need shadow proxies and implements a new Rete algorithm that is faster for retracts. You can get a nightly build from here, I'd be interested to find out how broken 5.0 is :) https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/ trunk/target/ We still have more performnace work to do, the items are known, just a matter of time, not all will make 5.0 though. but the main items include: 1) bytecode compiled Rete network, instead of interpreted nodes. I'm hoping this will have a large impact, reducing GC and general indirection and recursive method call frames. 2) true modify, instead of a retract+assert, will also remove the need for activation normalistaion that we do for TMS and the agenda event model. 3) range indexing (initially literals, but would like to explore variables too). Steve, before he left fedex, was creating a simulator for this use case, but removing anything business sensitive. So that we could use it publicly as a benchmark and to help us tune the engine. Are you still working on this? Steve use to chat to us on irc, can I ask you to pop on for a chat? http://labs.jboss.org/drools/irc.html mark Thanks Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Kneusel Sent: Thursday, June 26, 2008 12:47 PM To: rules-users@lists.jboss.org Subject: [rules-users] Drools 4 poor performance scaling? I am testing Drools 4 for our application and while sequential mode
RE: [rules-users] QueryResult.getFactHandles bug?
Looks like there's a JIRA for this now. Some feedback would have been
nice, however.
http://jira.jboss.com/jira/browse/JBRULES-1649
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fenderbosch,
Eric
Sent: Monday, June 16, 2008 11:00 AM
To: Rules Users List
Subject: RE: [rules-users] QueryResult.getFactHandles bug?
Any feedback on this? Just curious, we've worked around it, but I'd
like to know if my assumption was wrong or if this is an actual problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fenderbosch,
Eric
Sent: Monday, June 09, 2008 11:39 AM
To: rules-users@lists.jboss.org
Subject: [rules-users] QueryResult.getFactHandles bug?
I didn't find a JIRA for this and I'm pretty sure my test is valid.
QueryResult.getFactHandles() seems to be only returning [fid:-1:X:null]
I'm using 4.0.7.
Here's my test case:
public void testQueryResults() throws Exception {
StatefulSession workingMemory = DroolsUtil.getWorkingMemory();
TestFact testFact = new TestFact();
String id = 1234;
testFact.setId(id);
FactHandle testHandle = workingMemory.insert(testFact);
System.out.println(testHandle);
Object[] args = {id};
int resultCount = 0;
int factCount = 0;
int handleCount = 0;
Object fact = null;
FactHandle handle = null;
// query getTestFact(String _id)
// TestFact(id == _id)
// end
QueryResults queryResults =
workingMemory.getQueryResults(getTestFact, args);
IteratorQueryResult iterator = queryResults.iterator();
while (iterator.hasNext()) {
resultCount++;
QueryResult result = iterator.next();
FactHandle[] handles = result.getFactHandles();
for (FactHandle h : handles) {
handleCount++;
handle = h;
}
for (int i = 0; i result.size(); i++) {
factCount++;
fact = result.get(i);
}
}
System.out.println(handle);
assertTrue(resultCount == 1);
assertTrue(factCount == 1);
assertTrue(testFact == fact);
assertTrue(handleCount == 1);
// this fails
assertTrue(testHandle == handle);
}
TestFact is very simple, using id in hashCode and equals.
Am I using getFactHandles correctly?
Thanks.
___
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
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] QueryResult.getFactHandles bug?
Any feedback on this? Just curious, we've worked around it, but I'd
like to know if my assumption was wrong or if this is an actual problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fenderbosch,
Eric
Sent: Monday, June 09, 2008 11:39 AM
To: rules-users@lists.jboss.org
Subject: [rules-users] QueryResult.getFactHandles bug?
I didn't find a JIRA for this and I'm pretty sure my test is valid.
QueryResult.getFactHandles() seems to be only returning [fid:-1:X:null]
I'm using 4.0.7.
Here's my test case:
public void testQueryResults() throws Exception {
StatefulSession workingMemory = DroolsUtil.getWorkingMemory();
TestFact testFact = new TestFact();
String id = 1234;
testFact.setId(id);
FactHandle testHandle = workingMemory.insert(testFact);
System.out.println(testHandle);
Object[] args = {id};
int resultCount = 0;
int factCount = 0;
int handleCount = 0;
Object fact = null;
FactHandle handle = null;
// query getTestFact(String _id)
// TestFact(id == _id)
// end
QueryResults queryResults =
workingMemory.getQueryResults(getTestFact, args);
IteratorQueryResult iterator = queryResults.iterator();
while (iterator.hasNext()) {
resultCount++;
QueryResult result = iterator.next();
FactHandle[] handles = result.getFactHandles();
for (FactHandle h : handles) {
handleCount++;
handle = h;
}
for (int i = 0; i result.size(); i++) {
factCount++;
fact = result.get(i);
}
}
System.out.println(handle);
assertTrue(resultCount == 1);
assertTrue(factCount == 1);
assertTrue(testFact == fact);
assertTrue(handleCount == 1);
// this fails
assertTrue(testHandle == handle);
}
TestFact is very simple, using id in hashCode and equals.
Am I using getFactHandles correctly?
Thanks.
___
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
[rules-users] QueryResult.getFactHandles bug?
I didn't find a JIRA for this and I'm pretty sure my test is valid.
QueryResult.getFactHandles() seems to be only returning [fid:-1:X:null]
I'm using 4.0.7.
Here's my test case:
public void testQueryResults() throws Exception {
StatefulSession workingMemory = DroolsUtil.getWorkingMemory();
TestFact testFact = new TestFact();
String id = 1234;
testFact.setId(id);
FactHandle testHandle = workingMemory.insert(testFact);
System.out.println(testHandle);
Object[] args = {id};
int resultCount = 0;
int factCount = 0;
int handleCount = 0;
Object fact = null;
FactHandle handle = null;
// query getTestFact(String _id)
// TestFact(id == _id)
// end
QueryResults queryResults =
workingMemory.getQueryResults(getTestFact, args);
IteratorQueryResult iterator = queryResults.iterator();
while (iterator.hasNext()) {
resultCount++;
QueryResult result = iterator.next();
FactHandle[] handles = result.getFactHandles();
for (FactHandle h : handles) {
handleCount++;
handle = h;
}
for (int i = 0; i result.size(); i++) {
factCount++;
fact = result.get(i);
}
}
System.out.println(handle);
assertTrue(resultCount == 1);
assertTrue(factCount == 1);
assertTrue(testFact == fact);
assertTrue(handleCount == 1);
// this fails
assertTrue(testHandle == handle);
}
TestFact is very simple, using id in hashCode and equals.
Am I using getFactHandles correctly?
Thanks.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] Updating an existing fact w/o using fact handle
Thanks.
What I've done is add an insertOrUpdate method on a util class we use.
How efficient is getFactHandle? Is it a simple HashMap lookup? Or
would we be better off keeping our own map of handles-facts?
public static FactHandle insertOrUpdate(Object fact, boolean dynamic) {
FactHandle factHandle = workingMemory.getFactHandle(fact);
if (factHandle == null) {
return workingMemory.insert(fact, dynamic);
}
workingMemory.update(factHandle, fact);
return factHandle;
}
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edson Tirelli
Sent: Saturday, May 31, 2008 9:12 AM
To: Rules Users List
Subject: Re: [rules-users] Updating an existing fact w/o using fact
handle
Nope. You must use the update method. You can get the previous fact
handle using the get method in working memory if you still have the
original non-modified object, or if behavior is equals based, using an
equals object.
[]
Edson
2008/5/30 Fenderbosch, Eric [EMAIL PROTECTED]:
Is it required to use WorkingMemory.update to update an existing
fact?
I thought if assert behavior was set to equality and you
implemented the
equals method properly, then you could simply use
WorkingMemory.insert
to overwrite a fact in working memory with a new version. If
this isn't
the case, then are there other settings that will give this
behavior?
I'm using 4.0.7.
Thanks for any help.
Eric
Here's my RuleBaseConfiguration:
AlphaNodeHashingThreshold : 3
CompositeKeyDepth : 3
ExecutorServiceorg.drools.concurrent.DefaultExecutorService
RuleBaseUpdateHandler :
org.drools.base.FireAllRulesRuleBaseUpdateListener
AgendaGroupFactory :
[EMAIL PROTECTED]
AssertBehaviour : equality
ConflictResolver :
[EMAIL PROTECTED]
ConsequenceExceptionHandler :
[EMAIL PROTECTED]
LogicalOverride : discard
SequentialAgenda : sequential
AlphaMemory : false
IndexLeftBetaMemory : true
IndexRightBetaMemory : true
MaintainTms : true
RemoveIdenities : true
Sequential : false
ShadowProxy : true
ShareAlphaNodes : true
ShareBetaNodes : true
UseStaticObjensis : false
My TestFact class:
public class TestFact {
private String id;
private String value;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
@Override
public int hashCode() {
return id.hashCode();
}
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (!(obj instanceof TestFact)) return false;
TestFact other = (TestFact) obj;
// not null safe, i know
return this.id.equals(other.id);
}
}
And the JUnit Test Case that fails:
public void testFactUpdate() throws Exception {
TestFact testFact = new TestFact();
testFact.setId(1234);
testFact.setValue(old);
FactHandle testFactHandle =
workingMemory.insert(testFact);
TestFact updatedFact = new TestFact();
updatedFact.setId(1234);
updatedFact.setValue(new);
FactHandle updatedFactHandle =
workingMemory.insert(updatedFact);
// using workingMemory.update here works
// passes
assertTrue(testFactHandle == updatedFactHandle);
TestFact retrievedTestFact = (TestFact)
workingMemory.getObject(testFactHandle);
// fails
assertEquals(new,
retrievedTestFact.getValue());
}
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
