[rules user] different behavior on double type
by Zeke
Hi, guys:
I am using Drools 4.0.7. I find a strange behavior. When my LHS is
"Message( varDouble == 99.9 )" and "varDouble" equals "new Double(99.9)",
the condition is true. But when my LHS is "Message( types.doubleType ==
99.9 )" and the "doubleType" field is also equal to "new Double(99.9)", the
condition is false. I debug the code, and find that:
When the LHS is "Message( varDouble == 99.9 )", the logic will handle the
literal 99.9 as *Double.valueOf( “99.9” )*, and the comparison is between *(new
Double(99.9)).doubleValue(*) and *Double.valueOf( “99.9” ).doubleValue()*,
When the LHS is "Message( types.doubleType == 99.9 )", the logic is
different from above. The comparison is between *new BigDecimal((Double)
99.9, MathContext.DECIMAL64)* (which double value is 99.90000000000001) and
*new BigDecimal(“99.9”, MathContext.DECIMAL64)* (which double value is
99.9).
I think we need make things consistent. "varDouble" and
"types.doubleType" are of the same type and value. It doesn't make sense to
have different behavior just because of one field is nesting while the
other is not. I know Drools is using MVEL to evaluate the condition. But I
am not sure it is a MVEL bug or Drools uses MVEL wrong. It will be much
appreciated if you can give me any comments!
14 years, 2 months
Possible "memory leak" in 5.3 with update?
by thenim
I'm using a stateful session (in a slightly odd way - obviously this is the
problem), I have a stream of "messages" coming into my system and each
message one of a set of unique keys. Now my rules test various attibutes of
this message and makes some changes (to the messages) etc. (the rules aren't
the problem here - infact in my test case, I have no rules).
I tested the "normal" approach where each message is inserted and the fact
handle retained, and subsequently after firing, the handle is removed (yes
this sounds like a good case for Fusion, except for the making changes bit.)
I noticed that I could get better throughput, if took the following
approach:
1. On the first time the unique key is detected, the handle is saved
2. Then each time a message with that key is received, "update" is called
with the handle for that key
Now, the important thing here is that the "fact" is a *different* object not
an updated version of the original associated with the handle.
Now with this approach, I was getting better numbers, however every so often
there would be a "pause", with GC details being printed out, I see
immediately that it's sitting there doing full GC's very frequently, and
switching to the concurrent collector, I can see mode failures regularly
(i.e. full GCs). With a low message rate, I didn't notice it initially, but
with higher message rates, this is a serious issue.
It appears that the approach I've taken highlights a "leak". I wanted to
find out if others have encountered this before digging around in the code,
for the moment, I will "fix" my approach so that I update the "same object"
- but is "update" not meant to be used this way?
Thanks,
Nim
--
View this message in context: http://drools.46999.n3.nabble.com/Possible-memory-leak-in-5-3-with-update...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 2 months
need design suggestion
by Joe Zendle
Hi,
Trying to build net mgmt system but having problem with basic cause/effect
(mostly not understanding the engine).
I have a a Port object that contains a Card object. They both have separate
states (up or down). I want to have a Port go to down state if the
containing Card goes to down state - very basic now until i get the feel of
it.
The state of the Card changes if a Notification is injected into the
session (at least this is my understanding)
Here are my rules:
rule "card going down"
when
$card : Card($name : name , state == State.UP)
$notif : Notification( id == $name, type == NotificationType.CARD ,
state == State.DOWN )
then
System.out.println(" got notification for card down " + $card );
modify($card) {
setState(State.DOWN);
}
retract($notif);
end
// is the following rule correct??
rule "port going down"
when
$port : Port($name : name , state == State.UP, $card : card)
Card ( state == State.DOWN) from $card
then
System.out.println(" port down because card is down port: " + $port +
" card: " + $card );
modify($port) {
setState(State.DOWN);
}
end
Here is the test case in a nutshell:
Port port1 = new Port();
Port port2 = new Port();
port1.setName("port1");
port2.setName("port2");
Card card1 = new Card();
card1.setName("port1 card1")
port1.setCard(card1);
// stateful session
ksession.insert(port1);
ksession.insert(port2);
ksession.insert(card1);
System.out.println(" firing rules");
new Thread(new Runnable() {
public void run() {
ksession.fireUntilHalt();
}
}).start();
System.out.println("*** injecting notification down");
Notification notif = new Notification();
notif.setType(NotificationType.CARD);
notif.setState(State.DOWN);
notif.setId("port1 card1");
FactHandle notifHandle = ksession.insert(notif);
ksession.halt();
ksession.dispose()
I would expect the card down notification to cause the port to do down by
the second rule above but it does not fire.
Here is output
card1: Card [state=UP, name=port1 card1,
ne=org.plugtree.examples.model.NE@1e2670b]
OBJECT ASSERTED value:Port [state=UP, name=port1, card=Card [state=UP,
name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b]] factId: 1
OBJECT ASSERTED value:Port [state=UP, name=port2, card=Card [state=UP,
name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b]] factId: 3
OBJECT ASSERTED value:Card [state=UP, name=port1 card1,
ne=org.plugtree.examples.model.NE@1e2670b] factId: 5
firing rules
3
*** injecting notification down
ACTIVATION CREATED rule:card going down activationId:card going down [6, 5]
declarations: $name=port1 card1(5);
$notif=org.plugtree.examples.model.Notification@4a9a7d(6); $card=Card
[state=UP, name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b](5)
OBJECT ASSERTED value:org.plugtree.examples.model.Notification@4a9a7dfactId: 6
BEFORE ACTIVATION FIRED rule:card going down activationId:card going down
[6, 5] declarations: $name=port1 card1(5);
$notif=org.plugtree.examples.model.Notification@4a9a7d(6); $card=Card
[state=UP, name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b](5)
got notification for card down Card [state=UP, name=port1 card1,
ne=org.plugtree.examples.model.NE@1e2670b]
OBJECT MODIFIED value:Card [state=DOWN, name=port1 card1,
ne=org.plugtree.examples.model.NE@1e2670b] factId: 5
OBJECT RETRACTED value:org.plugtree.examples.model.Notification@4a9a7dfactId: 6
AFTER ACTIVATION FIRED rule:card going down activationId:card going down
[-1, 5] declarations: $name=port1 card1(5); $card=Card [state=DOWN,
name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b](5)
Is the second rule written incorrectly? or do i have a gap in my
expectations of how the engine should work (or both)
Thanks in advance,
Joe.
14 years, 2 months
Need drl help for arraylist
by arup
Hi all,
i need to write a rule to compare a String with a list of Strings (say
String[] nameList).
Person()
{
String name;
}
Values()
{
String[] nameList = new String[]{ "abc", "abcdef" }
}
how can i write the rule??
when
name of the person is same as any names in the nameList
then
do .....
i have tried different rule but still not able to get the desired output.
Thanks a lot in advance.... :) :) :)
--
View this message in context: http://drools.46999.n3.nabble.com/Need-drl-help-for-arraylist-tp3883683p3...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 2 months
Get rid of finalize() in KnowledgeSession
by Lubos
Hi,
My application uses many threads, each one creates KnowledgeSession from a
common shared KnowledgeBase to perform a task. The task is fast and at the
end session is disposed. When the thread starts to perform next task it
creates new session.
We had a scalability issues because of garbage collection. It happened too
often and took too long so we could not benefit from adding more CPUs. No GC
tuning helped.
After analysis I commented out finalize() method, which only calls
dispose(), which I call anyway after I'm done with the session. That was the
only change, i didn't modify application or JVM settings. Now the
application scales very well and all garbage collections are lighting fast.
After this experience I'm sure I will comment out finalize() in every drools
release I will use in the future, but maybe you could consider removing it
in the official release?
Lubos
--
View this message in context: http://drools.46999.n3.nabble.com/Get-rid-of-finalize-in-KnowledgeSession...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 2 months
How best to get back the updates that rules perform on declarative fact objects onto the domain objects (Dynamic fact generation with Declarative Fact Model)
by Vidya
Hi,
I am trying to evaluate using Drools in our EDM product. Our domain model is
very generic and complicated to be used as is as the fact model. Also new
domain entities will be added frequently and we would not want to write the
java fact model and supply the jar to the application (which needs
application bouncing...). So we may have to implement dynamic code
generation (using say javaassist).
Now I see that it can be partly achieved with the use of declarative fact
model (which does the dynamic code generation part for us).
But I have these questions -
When the rules fire, any update it makes on the fact needs to be updated
back onto our domain object obviously. Given that the fact model could be
potentially big, we were wondering
- if there can be anyway by which the application can be notified of
updates to the declared fact so we can copu only the changed attributes
backour domain object instead of copying all attributes back
OR
- if there was any way to introduce a dynamic proxy to the declared facts
so that the update (setXXX()) would have been called on the proxy which in
turn could update our domain object directly. As I see, this cannot be done
currently as the declarative facts are concrete classes and do not implement
any interface (its not possible to declare interfaces in drl files)
Is there any other better way to achieve this or should we go for dynamic
code generation in our application itself as mentioned in the beginning and
supply them as facts?
Thanks
Vidya
--
View this message in context: http://drools.46999.n3.nabble.com/How-best-to-get-back-the-updates-that-r...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 2 months
Rule firing issue in Drools 5.1.1...
by prashant.badhe
Hi,
Following are details of our configurations for Drools:
1. Drools v 5.1.1
2. Drools statefull kSession is initialized using Spring framework
3. We are using Resource scanner through change-set.xml. Scan interval is
set as 1 second. drools.Clocktype=realtime. drools.agent.newInstance=false.
4. There are about 8 DRL resources in the repository folder that resource
scanner scans.
5. Each DRL file has multiple rules. Within each DRL file, I am using same
aganda-group.
Issue:
After web server startup, it is observed that rules from some of the DRL
files fires. But, rules from 1 DRL file DO NOT fire at all.
There are no compilation errors/warnings appearing in log files after web
server startup.
If I remove this DRL file from repository (this is the location which
resource scanner scans) and copy it again after say 2-3 seconds, then the
rules from this file starts firing when appropriate facts are introduced in
WM.
Earlier I was using fireUntilHalt() to trigger rules, but now I am issuing
fireAllRules(). This was changed as I observed a 100% CPU consumption issue
when fireUntilHalt() even when the application is in idle state. See
"http://drools.46999.n3.nabble.com/fireUntilHalt-is-doing-busy-wait-and-co..."
I am using resource scanner feature to dynamically add/remove DRL files
without requiring restart of web server on production servers.
Does anybody faced similar issue in Drools 5.1.1 final?
Does resource scanner requires re-initialization of kSession after
add/update of DRL file in repository folder?
Thanks in advance,
Prashant Badhe
--
View this message in context: http://drools.46999.n3.nabble.com/Rule-firing-issue-in-Drools-5-1-1-tp388...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 2 months
