Re: [rules-users] Drools facts using POJO accessor methods error
yes, thanks... but Guvnor has too much features for our aim -- View this message in context: http://drools.46999.n3.nabble.com/Drools-facts-using-POJO-accessor-methods-error-tp3780387p3783558.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] [Drools Planner] Hard constraint appears to be ignored - How to isolate a working memory corruption in drools expert
Hi Reinis,
So drools-core 5.4.0.Beta2 doesn't fix it?
Then there might be another working memory corruption bug left in drools
expert.
Read the manual section about Delta score calculation to understand
why there's a presumed and a real workingMemory.
Isolating a working memory corruption is a PITA... but if you want to go
for it, here's how:
here's how I usually isolate such a bug to a small reproducable unit
test:
- Turn on environmentMode TRACE so it crashes as fast as possible
- Turn on TRACE logging.
http://docs.jboss.org/drools/release/5.4.0.Beta1/drools-planner-docs/html_single/index.html#d0e2450
So you see something like this:
INFO Solver started: time spend (0), score (-6), new best score (-6),
random seed (0).
TRACE Ignoring not doable move (col0@row0 = row0).
TRACE Move score (-4), accepted (true) for move (col0@row0 =
row1).
TRACE Move score (-4), accepted (true) for move (col0@row0 =
row2).
TRACE Move score (-4), accepted (true) for move (col0@row0 =
row3).
...
TRACE Move score (-3), accepted (true) for move (col1@row0 =
row3).
...
TRACE Move score (-3), accepted (true) for move (col2@row0 =
row3).
...
TRACE Move score (-4), accepted (true) for move (col3@row0 =
row3).
DEBUG Step index (0), time spend (6), score (-3), new best score
(-3), accepted move size (12) for picked step (col1@row0 = row3).
...
DEBUG Step index (1), time spend (10), score (-2), new best score
(-2), accepted move size (12) for picked step (...).
...
- If there's a construction heuristic that doesn't crash: remove it by:
-- run only the construction heuristic config
-- take the output solution as the new input solution
-- remove the construction heuristic config
- If it doesn't crash in step 0: remove non-crashing steps before it
-- run it just before the step it crashes and take the output solution
as the input solution
-- verify that it now crashes in step 0 (*)
- If it doesn't crash in the first move: remove non-crashing move's
before it
-- Open DefaultDecider.decideNextStep(LocalSearchStepScope) and add
moveIterator.next().
For example, if move 6 crashes:
public void decideNextStep(LocalSearchStepScope localSearchStepScope) {
WorkingMemory workingMemory = localSearchStepScope.getWorkingMemory();
IteratorMove moveIterator =
selector.moveIterator(localSearchStepScope);
// BEGIN
moveIterator.next();
moveIterator.next();
moveIterator.next();
moveIterator.next();
moveIterator.next(); // 5 next()'s
// END
while (moveIterator.hasNext()) {
Move move = moveIterator.next();
...
-- verify that it now crashes in move 0 (*)
(*) If it doesn't crash, that means that an earlier step or move
helped cause this issue.
Remove as many steps and moves as you can.
This means that the final unit test will have multiple fireAllRules():
... do move 1 ...
... fireAllRules
... undo move 1 ...
(... fireAllRules)
... do move 2 ...
... fireAllRules
// Now the WM is corrupted
- Now (and not sooner!), remove rules by commented out all the rules
in the DRL that doesn't stop the crashing
- Remove all the problem facts and planning entities that doesn't stop
the crashing.
- Now the problem should be small enough to rewrite it in a simple
unit test for Drools Expert.
Op 27-02-12 23:43, Reinis schreef:
Hello,
I did all the suggestions from Geoffrey (thanks sir) and now the TRACE is
failing with an additional rule:
java.lang.IllegalStateException: The presumedScore (0hard/0soft) is corrupted
because it is not the realScore (0hard/-1soft).
Presumed workingMemory:
Score rule (penalize late assignments) has count (11) and weight total
(8).
Score rule (reward Resource consolidation) has count (7) and weight total
(7).
Real workingMemory:
Score rule (penalize late assignments) has count (11) and weight total
(*7*).
Score rule (reward Resource consolidation) has count (*8*) and weight
total (*8*).
The offending rules look like this:
rule penalize late Assignments
when
$project : Project(kickOff != null, $kickOff : kickOff)
$assignment : Assignment(project == $project)
eval($assignment.getInterval().getStart().isAfter($kickOff))
then
insertLogical(new IntConstraintOccurrence(penalize late
assignments, ConstraintType.NEGATIVE_SOFT,
new Duration($kickOff,
$assignment.getInterval().getStart()).toStandardDays().getDays(),
$assignment, $project));
end
rule reward Resource consolidation
when
$leftAssignment : Assignment($project : project, $leftResource
: resource != null, $leftId : id, $leftIntervalStartMillis :
intervalStartMillis)
$rightAssignment : Assignment(project == $project, resource ==
$leftResource, id != $leftId, intervalStartMillis= $leftIntervalStartMillis)
eval(new
[rules-users] Problem with events in thr futurs with realtime option !!
Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? *$a : List() from collect(Event1() over window:time(2s) from entry-point point) * // work Bur why *$a : Event1() over window:time(2s) from entry-point point) * doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context: http://drools.46999.n3.nabble.com/Problem-with-events-in-thr-futurs-with-realtime-option-tp3783769p3783769.html Sent from the Drools: User forum 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] Slinding window !
Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? $a : List() from collect(Event1() over window:time(2s) from entry-point point) // work Bur why $a : Event1() over window:time(2s) from entry-point point) doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3783772.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Slinding window !
I can confirm (using 5.3.0) that after advance the clock to 1 insert an event with timestamp 1, advance the clock to 3 insert another one with timestamp 3 advance the clock to 4 fire all rules a rule with Event() over window:time( 2s ) will fire twice (2 times). There is no difference between STREAM and CLOUD mode. Indeed, the documentation (Fusion, 2.6.1, Sliding Time Windows) appears to tell another story: Sliding Time Windows allow the user to write rules that will only match events occurring in the last X time units. This is quite explicit. Also, please note that firing all rules after each insertion produces the expected results; the rule firings at T=3 and T=4 show only one event in the window. Even more surprisingly, running a rule that collects over a sliding window works as intuitively expected: $l: List() from collect( Event() over window:time( 2s ) ) Here the List will never contain more than one element, even when the simple pattern (shown above) fires twice. -W On 28/02/2012, Hassan azbak...@gmail.com wrote: Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? $a : List() from collect(Event1() over window:time(2s) from entry-point point) // work Bur why $a : Event1() over window:time(2s) from entry-point point) doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3783772.html Sent from the Drools: User forum 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
[rules-users] Order of Execution on Messages
We are currently authoring rules using Drools 5.3 and using jBPM 5.2 for orchestration. The situation we have is as follows: Certain groups of rules can execute on n number of messages in any order(i.e the order in which the consequences occur does not matter). The problem comes in later in the process when those same n messages need to have their consequences happen in a certain order. Is there a good way to handle this? We have thought about appending messages to a queue and just operating on one message at a time however this seems slow. In addition when utilizing jBPM and drools what is the best way to batch data in and out of the session. I understand starting a new session is cheap but was hoping there may be a way to have jBPM insert n records at a time and just continue to read from the db until no more records are returned. TIA! -- View this message in context: http://drools.46999.n3.nabble.com/Order-of-Execution-on-Messages-tp3784013p3784013.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Order of Execution on Messages
On 28/02/2012, gboro54 gbor...@gmail.com wrote:
We are currently authoring rules using Drools 5.3 and using jBPM 5.2 for
orchestration. The situation we have is as follows: Certain groups of rules
can execute on n number of messages in any order(i.e the order in which the
consequences occur does not matter). The problem comes in later in the
process when those same n messages need to have their consequences happen in
a certain order. Is there a good way to handle this? We have thought about
appending messages to a queue and just operating on one message at a time
however this seems slow.
seems seems to be not from experience. How big is n, how slow is slow?
A simple test will tell you all.
Nevertheless, there may be relatively slow and relatively fast
techniques for achieving firing in order. (I assume that ordering the
results is not an alternative to firing in order.)
(a) Use dynamic salience, provided there is some integer ordinal as a
field of Message.
(b) Use a class Container { ListMessage msgs } as a fact, containing
all Messages in msgs. Insert Container as fact. Assuming your rules
run at salience 0 or higher:
rule nextMessage
salience -100
when
Container( $msgs: msgs, eval( $msgs.size() 0 ) )
then
insert( msgs.remove( 0 ) );
end
rule noMoreMessages
salience -100
when
$cont: Container( $msgs: msgs, eval( $msgs.size() == 0 ) )
then
retract( $cont );
end
(This is a good example for the rule design pattern Proxy Facts.)
-W
In addition when utilizing jBPM and drools what is
the best way to batch data in and out of the session. I understand starting
a new session is cheap but was hoping there may be a way to have jBPM insert
n records at a time and just continue to read from the db until no more
records are returned.
TIA!
--
View this message in context:
http://drools.46999.n3.nabble.com/Order-of-Execution-on-Messages-tp3784013p3784013.html
Sent from the Drools: User forum 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
Re: [rules-users] Order of Execution on Messages
Agreed that seems is not from experience in this current endeavor. However previous implementations it has been faster to insert multiple facts and execute once rather then insert one at a time and execute... A proxy fact may be a good idea -- View this message in context: http://drools.46999.n3.nabble.com/Order-of-Execution-on-Messages-tp3784013p3784138.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Order of Execution on Messages
dynamic salience is perfect(not sure how i missed that in the docs -- View this message in context: http://drools.46999.n3.nabble.com/Order-of-Execution-on-Messages-tp3784013p3784267.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Slinding window !
This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple patterns. For instance: X() over window:time( 1m ) Y() over window:time( 1m ) This will create pairs of [X,Y] only for the X's and Y's that happened in the last minute, as intended. An X that just happened will not match an Y that happened 2 minutes ago. Edson On Tue, Feb 28, 2012 at 7:18 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I can confirm (using 5.3.0) that after advance the clock to 1 insert an event with timestamp 1, advance the clock to 3 insert another one with timestamp 3 advance the clock to 4 fire all rules a rule with Event() over window:time( 2s ) will fire twice (2 times). There is no difference between STREAM and CLOUD mode. Indeed, the documentation (Fusion, 2.6.1, Sliding Time Windows) appears to tell another story: Sliding Time Windows allow the user to write rules that will only match events occurring in the last X time units. This is quite explicit. Also, please note that firing all rules after each insertion produces the expected results; the rule firings at T=3 and T=4 show only one event in the window. Even more surprisingly, running a rule that collects over a sliding window works as intuitively expected: $l: List() from collect( Event() over window:time( 2s ) ) Here the List will never contain more than one element, even when the simple pattern (shown above) fires twice. -W On 28/02/2012, Hassan azbak...@gmail.com wrote: Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? $a : List() from collect(Event1() over window:time(2s) from entry-point point) // work Bur why $a : Event1() over window:time(2s) from entry-point point) doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3783772.html Sent from the Drools: User forum 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
Re: [rules-users] 5.4.0.Beta2 parse error in consequence /* in string
Working on the sign contributer agreement. Have to fill out the permission slip at the company I work for to contribute back in my free time. I submitted at merge request https://github.com/droolsjbpm/drools/pull/102 If the commit looks fine but just waiting on the Contributor Agreementhttp://www.athico.com/Getting_Involved/gettinginvolved.html#d0e319. If there is something I did wrong in the commit or comment just looking for feedback. Just going to add the // /* to the array to test it. Yeah I didn't test the // with 5.3.0 but I am pretty sure it happens in latest master . I was going to use the commit https://github.com/benbennett/drools/commit/d5325b93589aafdfaeb1f45077eb4da3a8970a2f. And add // and /* to the array to cycle through. 2012/2/28 Mark Proctor mproc...@codehaus.org On 27/02/2012 15:44, Benjamin Bennett wrote: I had created issue JBRULES-3399 for the issue. I tracked it a bit , it is any comment. // or /* , think the lexar expression for comment isn't correct . I am working towards a fix but not a antlr expert. I have used yacc. just a reminder to read this page, on how to correctly comment your commits, how to submit pull requests etc: http://www.athico.com/Getting_Involved/gettinginvolved.html Mark On Mon, Feb 27, 2012 at 1:38 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: Submitted: JBRULES-3401. -W On 24/02/2012, Benjamin Bennett benbenn...@gmail.com wrote: Just passing on I am using the drools 5.4.0Beta2 The following doesn't compile using the mvel dialect . rule some rule when fact: Fact() then BasicFact fault= new BasicFact( /*); end but rule some rule when fact: Fact() then BasicFact fault= new BasicFact( / *); end does compile some how /* is being parsed as an expression I think and not a string literal. Thanks, Ben ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Sincerely, Benjamin Bennett 314.246.0645 benbenn...@gmail.com For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. Richard Feynman ___ rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Sincerely, Benjamin Bennett 314.246.0645 benbenn...@gmail.com For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. Richard Feynman ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Slinding window !
I think there is a misunderstanding - expiry is not an issue. We have two events, dated (say) 1 and 3 and it is now 4 o'clock and the window looks back 2 units: Event() over window:time(2) This fires twice! -W On 28/02/2012, Edson Tirelli ed.tire...@gmail.com wrote: This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple patterns. For instance: X() over window:time( 1m ) Y() over window:time( 1m ) This will create pairs of [X,Y] only for the X's and Y's that happened in the last minute, as intended. An X that just happened will not match an Y that happened 2 minutes ago. Edson On Tue, Feb 28, 2012 at 7:18 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I can confirm (using 5.3.0) that after advance the clock to 1 insert an event with timestamp 1, advance the clock to 3 insert another one with timestamp 3 advance the clock to 4 fire all rules a rule with Event() over window:time( 2s ) will fire twice (2 times). There is no difference between STREAM and CLOUD mode. Indeed, the documentation (Fusion, 2.6.1, Sliding Time Windows) appears to tell another story: Sliding Time Windows allow the user to write rules that will only match events occurring in the last X time units. This is quite explicit. Also, please note that firing all rules after each insertion produces the expected results; the rule firings at T=3 and T=4 show only one event in the window. Even more surprisingly, running a rule that collects over a sliding window works as intuitively expected: $l: List() from collect( Event() over window:time( 2s ) ) Here the List will never contain more than one element, even when the simple pattern (shown above) fires twice. -W On 28/02/2012, Hassan azbak...@gmail.com wrote: Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? $a : List() from collect(Event1() over window:time(2s) from entry-point point) // work Bur why $a : Event1() over window:time(2s) from entry-point point) doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3783772.html Sent from the Drools: User forum 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
Re: [rules-users] Slinding window !
Yes, the misunderstanding is that an expiration is not a retract. Expiration does not cancel an activation. Retract does. So if you received an event dated T1, it match your pattern and the rule will activate. Then you receive event dated T3 and your rule activates again for the new event. Then when the clock advances to T4, the event at T1 expires and will not create any **new** matches for the rule, but it respects the activation that was **already created**. Then you fireAllRules() at time T4 and it will fire the 2 existing activations. This happens because of the 2-phase execution of the engine and the need to unify the semantics of event processing and rules processing. Imagine that the engine was, because of forward chaining, executing a long sequence of high priority activations that prevented the rule in discussion of being fired at time T1...T3. Only at T4 the engine had CPU cycles to execute the rule for event T1. If event expiration would cancel the activation, the engine would completely miss the rule execution because of lack of processing power. This is an extreme example, but perfectly illustrates what happens with events that expire immediately or within a few milliseconds. The application can also be designed to run in cycles, waiting as much as it wants to fireAllRules(), because it is guaranteed that it will not miss any events because of that. On the other hand, if you were running the engine with fireUntilHalt(), after inserting event T1, the activation would be created and fired asap. Key point: expiration != retraction Hope it helps, Edson On Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I think there is a misunderstanding - expiry is not an issue. We have two events, dated (say) 1 and 3 and it is now 4 o'clock and the window looks back 2 units: Event() over window:time(2) This fires twice! -W On 28/02/2012, Edson Tirelli ed.tire...@gmail.com wrote: This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple patterns. For instance: X() over window:time( 1m ) Y() over window:time( 1m ) This will create pairs of [X,Y] only for the X's and Y's that happened in the last minute, as intended. An X that just happened will not match an Y that happened 2 minutes ago. Edson On Tue, Feb 28, 2012 at 7:18 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I can confirm (using 5.3.0) that after advance the clock to 1 insert an event with timestamp 1, advance the clock to 3 insert another one with timestamp 3 advance the clock to 4 fire all rules a rule with Event() over window:time( 2s ) will fire twice (2 times). There is no difference between STREAM and CLOUD mode. Indeed, the documentation (Fusion, 2.6.1, Sliding Time Windows) appears to tell another story: Sliding Time Windows allow the user to write rules that will only match events occurring in the last X time units. This is quite explicit. Also, please note that firing all rules after each insertion produces the expected results; the rule firings at T=3 and T=4 show only one event in the window. Even more surprisingly, running a rule that collects over a sliding window works as intuitively expected: $l: List() from collect( Event() over window:time( 2s ) ) Here the List will never contain more than one element, even when the simple pattern (shown above) fires twice. -W On 28/02/2012, Hassan azbak...@gmail.com wrote: Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? $a : List() from collect(Event1() over window:time(2s) from entry-point point) // work Bur why $a : Event1() over window:time(2s) from entry-point point) doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3783772.html Sent from the Drools: User forum 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
Re: [rules-users] Slinding window !
OK, I suspected as much. But how do you explain that the List that's collected at T=4 by List() from collect( Event() over window(2) ) contains just one element? This means that the same pattern Event over window(2) produces two different sets of facts, at the same time! (I don't think that expiry is a good term for an event drifting out of a window, but that's not the point.) -W 2012/2/28 Edson Tirelli ed.tire...@gmail.com Yes, the misunderstanding is that an expiration is not a retract. Expiration does not cancel an activation. Retract does. So if you received an event dated T1, it match your pattern and the rule will activate. Then you receive event dated T3 and your rule activates again for the new event. Then when the clock advances to T4, the event at T1 expires and will not create any **new** matches for the rule, but it respects the activation that was **already created**. Then you fireAllRules() at time T4 and it will fire the 2 existing activations. This happens because of the 2-phase execution of the engine and the need to unify the semantics of event processing and rules processing. Imagine that the engine was, because of forward chaining, executing a long sequence of high priority activations that prevented the rule in discussion of being fired at time T1...T3. Only at T4 the engine had CPU cycles to execute the rule for event T1. If event expiration would cancel the activation, the engine would completely miss the rule execution because of lack of processing power. This is an extreme example, but perfectly illustrates what happens with events that expire immediately or within a few milliseconds. The application can also be designed to run in cycles, waiting as much as it wants to fireAllRules(), because it is guaranteed that it will not miss any events because of that. On the other hand, if you were running the engine with fireUntilHalt(), after inserting event T1, the activation would be created and fired asap. Key point: expiration != retraction Hope it helps, Edson On Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I think there is a misunderstanding - expiry is not an issue. We have two events, dated (say) 1 and 3 and it is now 4 o'clock and the window looks back 2 units: Event() over window:time(2) This fires twice! -W On 28/02/2012, Edson Tirelli ed.tire...@gmail.com wrote: This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple patterns. For instance: X() over window:time( 1m ) Y() over window:time( 1m ) This will create pairs of [X,Y] only for the X's and Y's that happened in the last minute, as intended. An X that just happened will not match an Y that happened 2 minutes ago. Edson On Tue, Feb 28, 2012 at 7:18 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I can confirm (using 5.3.0) that after advance the clock to 1 insert an event with timestamp 1, advance the clock to 3 insert another one with timestamp 3 advance the clock to 4 fire all rules a rule with Event() over window:time( 2s ) will fire twice (2 times). There is no difference between STREAM and CLOUD mode. Indeed, the documentation (Fusion, 2.6.1, Sliding Time Windows) appears to tell another story: Sliding Time Windows allow the user to write rules that will only match events occurring in the last X time units. This is quite explicit. Also, please note that firing all rules after each insertion produces the expected results; the rule firings at T=3 and T=4 show only one event in the window. Even more surprisingly, running a rule that collects over a sliding window works as intuitively expected: $l: List() from collect( Event() over window:time( 2s ) ) Here the List will never contain more than one element, even when the simple pattern (shown above) fires twice. -W On 28/02/2012, Hassan azbak...@gmail.com wrote: Hi guys, While trying to understand how slinding window work, I realize that all exemples are given with accumulate or collect functions , I din't know why ?? $a : List() from collect(Event1() over window:time(2s) from entry-point point) // work Bur why $a : Event1() over window:time(2s) from entry-point point) doesn't work ??! Thanks, Youssef AZBAKH -- View this message in context:
Re: [rules-users] Slinding window !
This is tricky indeed and it is part of the design decisions we had to make. When you have a rule: when X() The rule cares about X. Whether X is an event or fact, whether X is in a sliding window was simply expired by the expiration policy. Because the rule cares about X, X has to be correct and the rule has to be fired for X unless it is explicitly retracted. When you have a rule that says: when List() from collect(X() ...) The rule does not care about the elements of the List individually, the rule cares about the List of elements. Quoting the text above: Because the rule cares about the List, the List has to be correct, i.e., reflect the current content at the time it fires. It is hard to see on paper, but as soon as you start applying it to use cases, it makes sense. For instance, you want to fire a rule to call the firefighters if the fire alarm is sounding. Even if it takes some time to do it, you want to call the fire fighters. On the other hand, you want to turn on the sprinklers if the average temperature is above X degrees... but since the time it raised over X degrees, something happened and the temperature lowered to under X degrees, so you don't want to turn on the sprinklers anymore because the current temperature is under the threshold, even if it was over in the past. It is tricky and there is no single right or wrong answer on this. It was a design decision. Edson 2012/2/28 Wolfgang Laun wolfgang.l...@gmail.com OK, I suspected as much. But how do you explain that the List that's collected at T=4 by List() from collect( Event() over window(2) ) contains just one element? This means that the same pattern Event over window(2) produces two different sets of facts, at the same time! (I don't think that expiry is a good term for an event drifting out of a window, but that's not the point.) -W 2012/2/28 Edson Tirelli ed.tire...@gmail.com Yes, the misunderstanding is that an expiration is not a retract. Expiration does not cancel an activation. Retract does. So if you received an event dated T1, it match your pattern and the rule will activate. Then you receive event dated T3 and your rule activates again for the new event. Then when the clock advances to T4, the event at T1 expires and will not create any **new** matches for the rule, but it respects the activation that was **already created**. Then you fireAllRules() at time T4 and it will fire the 2 existing activations. This happens because of the 2-phase execution of the engine and the need to unify the semantics of event processing and rules processing. Imagine that the engine was, because of forward chaining, executing a long sequence of high priority activations that prevented the rule in discussion of being fired at time T1...T3. Only at T4 the engine had CPU cycles to execute the rule for event T1. If event expiration would cancel the activation, the engine would completely miss the rule execution because of lack of processing power. This is an extreme example, but perfectly illustrates what happens with events that expire immediately or within a few milliseconds. The application can also be designed to run in cycles, waiting as much as it wants to fireAllRules(), because it is guaranteed that it will not miss any events because of that. On the other hand, if you were running the engine with fireUntilHalt(), after inserting event T1, the activation would be created and fired asap. Key point: expiration != retraction Hope it helps, Edson On Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I think there is a misunderstanding - expiry is not an issue. We have two events, dated (say) 1 and 3 and it is now 4 o'clock and the window looks back 2 units: Event() over window:time(2) This fires twice! -W On 28/02/2012, Edson Tirelli ed.tire...@gmail.com wrote: This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple patterns. For instance: X() over window:time( 1m ) Y() over window:time( 1m ) This will create pairs of [X,Y] only for the X's and Y's that happened in the last minute, as intended. An X that just happened will not match an Y that happened 2 minutes ago. Edson On Tue, Feb 28, 2012 at 7:18 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote: I can confirm (using 5.3.0) that after advance the clock to 1 insert an event with timestamp 1, advance the clock to 3 insert another one
Re: [rules-users] Slinding window !
All right, I can condense the discussion into a single recommendation for CEP with Fusion: If you want consistent real-time results from your rules, make sure that the Engine doesn't remain idle - evaluate each new situation immediately, or do not run the Engine intermittently at all (i.e., call fireUntilHalt()). -W 2012/2/28 Edson Tirelli ed.tire...@gmail.com This is tricky indeed and it is part of the design decisions we had to make. When you have a rule: when X() The rule cares about X. Whether X is an event or fact, whether X is in a sliding window was simply expired by the expiration policy. Because the rule cares about X, X has to be correct and the rule has to be fired for X unless it is explicitly retracted. When you have a rule that says: when List() from collect(X() ...) The rule does not care about the elements of the List individually, the rule cares about the List of elements. Quoting the text above: Because the rule cares about the List, the List has to be correct, i.e., reflect the current content at the time it fires. It is hard to see on paper, but as soon as you start applying it to use cases, it makes sense. For instance, you want to fire a rule to call the firefighters if the fire alarm is sounding. Even if it takes some time to do it, you want to call the fire fighters. On the other hand, you want to turn on the sprinklers if the average temperature is above X degrees... but since the time it raised over X degrees, something happened and the temperature lowered to under X degrees, so you don't want to turn on the sprinklers anymore because the current temperature is under the threshold, even if it was over in the past. It is tricky and there is no single right or wrong answer on this. It was a design decision. Edson 2012/2/28 Wolfgang Laun wolfgang.l...@gmail.com OK, I suspected as much. But how do you explain that the List that's collected at T=4 by List() from collect( Event() over window(2) ) contains just one element? This means that the same pattern Event over window(2) produces two different sets of facts, at the same time! (I don't think that expiry is a good term for an event drifting out of a window, but that's not the point.) -W 2012/2/28 Edson Tirelli ed.tire...@gmail.com Yes, the misunderstanding is that an expiration is not a retract. Expiration does not cancel an activation. Retract does. So if you received an event dated T1, it match your pattern and the rule will activate. Then you receive event dated T3 and your rule activates again for the new event. Then when the clock advances to T4, the event at T1 expires and will not create any **new** matches for the rule, but it respects the activation that was **already created**. Then you fireAllRules() at time T4 and it will fire the 2 existing activations. This happens because of the 2-phase execution of the engine and the need to unify the semantics of event processing and rules processing. Imagine that the engine was, because of forward chaining, executing a long sequence of high priority activations that prevented the rule in discussion of being fired at time T1...T3. Only at T4 the engine had CPU cycles to execute the rule for event T1. If event expiration would cancel the activation, the engine would completely miss the rule execution because of lack of processing power. This is an extreme example, but perfectly illustrates what happens with events that expire immediately or within a few milliseconds. The application can also be designed to run in cycles, waiting as much as it wants to fireAllRules(), because it is guaranteed that it will not miss any events because of that. On the other hand, if you were running the engine with fireUntilHalt(), after inserting event T1, the activation would be created and fired asap. Key point: expiration != retraction Hope it helps, Edson On Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun wolfgang.l...@gmail.com wrote: I think there is a misunderstanding - expiry is not an issue. We have two events, dated (say) 1 and 3 and it is now 4 o'clock and the window looks back 2 units: Event() over window:time(2) This fires twice! -W On 28/02/2012, Edson Tirelli ed.tire...@gmail.com wrote: This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple patterns. For instance: X() over window:time( 1m ) Y() over window:time( 1m ) This will create pairs of [X,Y] only for the
Re: [rules-users] Slinding window !
:) That works... as it was the reason fireUntilHalt() was created. Edson 2012/2/28 Wolfgang Laun wolfgang.l...@gmail.com All right, I can condense the discussion into a single recommendation for CEP with Fusion: If you want consistent real-time results from your rules, make sure that the Engine doesn't remain idle - evaluate each new situation immediately, or do not run the Engine intermittently at all (i.e., call fireUntilHalt()). -W 2012/2/28 Edson Tirelli ed.tire...@gmail.com This is tricky indeed and it is part of the design decisions we had to make. When you have a rule: when X() The rule cares about X. Whether X is an event or fact, whether X is in a sliding window was simply expired by the expiration policy. Because the rule cares about X, X has to be correct and the rule has to be fired for X unless it is explicitly retracted. When you have a rule that says: when List() from collect(X() ...) The rule does not care about the elements of the List individually, the rule cares about the List of elements. Quoting the text above: Because the rule cares about the List, the List has to be correct, i.e., reflect the current content at the time it fires. It is hard to see on paper, but as soon as you start applying it to use cases, it makes sense. For instance, you want to fire a rule to call the firefighters if the fire alarm is sounding. Even if it takes some time to do it, you want to call the fire fighters. On the other hand, you want to turn on the sprinklers if the average temperature is above X degrees... but since the time it raised over X degrees, something happened and the temperature lowered to under X degrees, so you don't want to turn on the sprinklers anymore because the current temperature is under the threshold, even if it was over in the past. It is tricky and there is no single right or wrong answer on this. It was a design decision. Edson 2012/2/28 Wolfgang Laun wolfgang.l...@gmail.com OK, I suspected as much. But how do you explain that the List that's collected at T=4 by List() from collect( Event() over window(2) ) contains just one element? This means that the same pattern Event over window(2) produces two different sets of facts, at the same time! (I don't think that expiry is a good term for an event drifting out of a window, but that's not the point.) -W 2012/2/28 Edson Tirelli ed.tire...@gmail.com Yes, the misunderstanding is that an expiration is not a retract. Expiration does not cancel an activation. Retract does. So if you received an event dated T1, it match your pattern and the rule will activate. Then you receive event dated T3 and your rule activates again for the new event. Then when the clock advances to T4, the event at T1 expires and will not create any **new** matches for the rule, but it respects the activation that was **already created**. Then you fireAllRules() at time T4 and it will fire the 2 existing activations. This happens because of the 2-phase execution of the engine and the need to unify the semantics of event processing and rules processing. Imagine that the engine was, because of forward chaining, executing a long sequence of high priority activations that prevented the rule in discussion of being fired at time T1...T3. Only at T4 the engine had CPU cycles to execute the rule for event T1. If event expiration would cancel the activation, the engine would completely miss the rule execution because of lack of processing power. This is an extreme example, but perfectly illustrates what happens with events that expire immediately or within a few milliseconds. The application can also be designed to run in cycles, waiting as much as it wants to fireAllRules(), because it is guaranteed that it will not miss any events because of that. On the other hand, if you were running the engine with fireUntilHalt(), after inserting event T1, the activation would be created and fired asap. Key point: expiration != retraction Hope it helps, Edson On Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun wolfgang.l...@gmail.com wrote: I think there is a misunderstanding - expiry is not an issue. We have two events, dated (say) 1 and 3 and it is now 4 o'clock and the window looks back 2 units: Event() over window:time(2) This fires twice! -W On 28/02/2012, Edson Tirelli ed.tire...@gmail.com wrote: This is correct and works as designed. Please note that a direct event expiration does NOT cause a rule to be cancelled. So using sliding windows in isolation will be useless: X() over window:time(...) Will activate and fire for every single X, and that is correct. Now, if you use sliding windows in combination with other CEs, then the results will be affected by the sliding window. This is perfectly clear with accumulate/collect, but also happens when you are using multiple
[rules-users] How to get my Eclipse Indigo ready to develop Guvnor 5.x
Hi group. Just a fun general question. I am interested in starting to help out one of our big clients using Guvnor 5.x make small tweaks to the GWT GUI as they request, and then possibly contribute some of these fixes to the general community. However, I am not sure what Eclipse Plug-ins I should add in order to get going with GWT. Here are the ones I'm going to add: GWT plug-in: http://code.google.com/eclipse/ JBoss-Tools latest: http://www.jboss.org/tools/download.html Maven plugin: Latest from eclipse marketplace What else? Any tips? -- View this message in context: http://drools.46999.n3.nabble.com/How-to-get-my-Eclipse-Indigo-ready-to-develop-Guvnor-5-x-tp3785861p3785861.html Sent from the Drools: User forum 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] Getting java.lang.ClassCastException: - using Drools 5.3
HI. I am getting following exception. Exception in thread main org.drools.RuntimeDroolsException: d1.rule.Rule_8f09c0aa35010080cb1e0dd40f6fEval4Invoker@f6f66af4 :* java.lang.ClassCastException: d1.rule.facts.Medication cannot be cast to d1.rule.facts.Procedure* at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:119) at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:178) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:72) at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:161) at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:458) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:386) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:134) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215) at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255) at d1.rule.facts.PatientFacts.loadFactsInSession(PatientFacts.java:6075) at d1.rule.DREvaluator.startEvaluation(DREvaluator.java:278) at d1.rule.DREvaluator.main(DREvaluator.java:72) Caused by: java.lang.ClassCastException: d1.rule.facts.Medication cannot be cast to d1.rule.facts.Procedure at d1.rule.Rule_8f09c0aa35010080cb1e0dd40f6fEval4Invoker.evaluate(Unknown Source) at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) Following is the rule. I found that due to or the Procedure block not runs. If I change or to and than procedure block executed the error not produced. I am not sure what's the problem, I am using Drool 5.3 rule 8f09c0aa35010080cb1e0dd40f6f when#conditions ( $cepFacts: CEPFacts(id==D1) and eval($cepFacts.initialize()) and ( ( $DxDate_1 : ( Medication( name equalsIgnoreCase Ofloxacin ) ) and eval($cepFacts.checkRelativeValues($DxDate_1) ) ) or ( $DxDate_2 : ( Procedure( name equalsIgnoreCase Pres antibiotic ) ) and eval($cepFacts.checkRelativeValues($DxDate_2) ) ) ) and ( $DxDate_3 : ( Medication( name equalsIgnoreCase Trazodone ) ) and eval($cepFacts.checkTimeIs($DxDate_3) ) ) then resultIds.add(8f09c0aa35010080cb1e0dd40f6f); end -- View this message in context: http://drools.46999.n3.nabble.com/Getting-java-lang-ClassCastException-using-Drools-5-3-tp3785966p3785966.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] How to get my Eclipse Indigo ready to develop Guvnor 5.x
Check this doc: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/README.md Cheers, Jervis On 2012/2/29 8:47, ndipiazza wrote: Hi group. Just a fun general question. I am interested in starting to help out one of our big clients using Guvnor 5.x make small tweaks to the GWT GUI as they request, and then possibly contribute some of these fixes to the general community. However, I am not sure what Eclipse Plug-ins I should add in order to get going with GWT. Here are the ones I'm going to add: GWT plug-in: http://code.google.com/eclipse/ JBoss-Tools latest: http://www.jboss.org/tools/download.html Maven plugin: Latest from eclipse marketplace What else? Any tips? -- View this message in context: http://drools.46999.n3.nabble.com/How-to-get-my-Eclipse-Indigo-ready-to-develop-Guvnor-5-x-tp3785861p3785861.html Sent from the Drools: User forum 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
Re: [rules-users] How to get my Eclipse Indigo ready to develop Guvnor 5.x
Wow! I'm blind. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/How-to-get-my-Eclipse-Indigo-ready-to-develop-Guvnor-5-x-tp3785861p3786138.html Sent from the Drools: User forum 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] Build Error: Unknown language MVEL
Hi, I'm using the guvnor that comes with the jbpm-5.2.0.Final-installer-full download. I have a package in which I've created a process with condition expressions. When I build the package, I get the following error message on the Drools designer: unable to parse xml : Exception class java.lang.IllegalArgumentException : Unknown language http://www.mvel.org/2.0 My business process definintion is attached to this post. Any ideas on why this could be happening please? http://drools.46999.n3.nabble.com/file/n3786348/patientVisit.xml patientVisit.xml -- View this message in context: http://drools.46999.n3.nabble.com/Build-Error-Unknown-language-MVEL-tp3786348p3786348.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Getting java.lang.ClassCastException: - using Drools 5.3
This is a bug in the DRL parser/builder. Even when you (as you should) omit the parentheses around the patterns Medication and Procedure (see below) you get the same exception: ( $Dx1 : Medication( name == Oflo ) and eval($x.check($Dx1) ) ) or ( $Dx2 : Procedure( name == Pre ) and eval($x.checks($Dx2) ) ) However, you can use a workaround with the semantically equivalent inline eval: ( $Dx1 : Medication( name == Oflo, eval($x.check($Dx1) ) or $Dx2 : Procedure( name == Pre, eval($x.checks($Dx2) )) Note: The similarity between treatment by Medication and Procedure suggests that there should be an interface Treatment implemented by both, so you might simplify this to $Dx1: Treatment( name == Oflo || == Pre, eval( $x.checks( $Dx1 ) ) -W On 29/02/2012, kashif10 kash...@yahoo.com wrote: HI. I am getting following exception. Exception in thread main org.drools.RuntimeDroolsException: d1.rule.Rule_8f09c0aa35010080cb1e0dd40f6fEval4Invoker@f6f66af4 :* java.lang.ClassCastException: d1.rule.facts.Medication cannot be cast to d1.rule.facts.Procedure* at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:119) at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:178) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:72) at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:161) at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:458) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:386) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:134) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215) at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255) at d1.rule.facts.PatientFacts.loadFactsInSession(PatientFacts.java:6075) at d1.rule.DREvaluator.startEvaluation(DREvaluator.java:278) at d1.rule.DREvaluator.main(DREvaluator.java:72) Caused by: java.lang.ClassCastException: d1.rule.facts.Medication cannot be cast to d1.rule.facts.Procedure at d1.rule.Rule_8f09c0aa35010080cb1e0dd40f6fEval4Invoker.evaluate(Unknown Source) at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) Following is the rule. I found that due to or the Procedure block not runs. If I change or to and than procedure block executed the error not produced. I am not sure what's the problem, I am using Drool 5.3 rule 8f09c0aa35010080cb1e0dd40f6f when#conditions ( $cepFacts: CEPFacts(id==D1) and eval($cepFacts.initialize()) and ( ( $DxDate_1 : ( Medication( name equalsIgnoreCase Ofloxacin ) ) and eval($cepFacts.checkRelativeValues($DxDate_1) ) ) or ( $DxDate_2 : ( Procedure( name equalsIgnoreCase Pres antibiotic ) ) and eval($cepFacts.checkRelativeValues($DxDate_2) ) ) ) and ( $DxDate_3 : ( Medication( name equalsIgnoreCase Trazodone ) ) and eval($cepFacts.checkTimeIs($DxDate_3) ) ) then resultIds.add(8f09c0aa35010080cb1e0dd40f6f); end -- View this message in context: http://drools.46999.n3.nabble.com/Getting-java-lang-ClassCastException-using-Drools-5-3-tp3785966p3785966.html Sent from the Drools: User forum 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
[rules-users] Some problems with Deploying drools-camel-sever 5.3.x in Weblogic 10.x
Hey everyone,
We have been trying to deploy drools-camel-server-5.3.x.Final.war from
droolsjbpm-integration-distribution-5.3.0.Final on WebLogic 10.3.3.
We hit a series of issues, of which I've opened up some issue tickets to
address:
1) strict web application container complains about web.xml (JBRULES-3403 -
https://issues.jboss.org/browse/JBRULES-3403) - web.xml needs to be
re-arranged to get it to work in weblogic 10.x.
2) There seems to be duplicate JPA persistence units
(https://issues.jboss.org/browse/JBRULES-3404)
I also experienced two other issues that I do not feel comfortable putting
on the issue tracker because they may be weblogic-specific:
3) When I tried to run a SOAP UI test on the drools server in Weblogic
10.3.3 I get this:
WARNING: Interceptor for {http://soap.jax.drools.org/}CommandExecutor has
thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: This class does not support SAAJ 1.1
at
org.apache.camel.component.cxf.CxfConsumer$1.checkFailure(CxfConsumer
.java:123)
at
org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:
102)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInv
okerInterceptor.java:58)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:44
1)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecu
tor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Se
rviceInvokerInterceptor.java:106)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
orChain.java:263)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainIniti
ationObserver.java:118)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(Abstract
HTTPDestination.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(
ServletController.java:223)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletCont
roller.java:205)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpr
ingServlet.java:113)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Ab
stractHTTPServlet.java:184)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractH
TTPServlet.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abstract
HTTPServlet.java:163)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:227)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecuri
tyHelper.java:125)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:300)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:183)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.doIt(WebAppServletContext.java:3686)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:3650)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
121)
at
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppS
ervletContext.java:2268)
at
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletC
ontext.java:2174)
at
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.j
ava:1446)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.UnsupportedOperationException: This class does not
support
SAAJ 1.1
at
weblogic.webservice.core.soap.SOAPMessageImpl.getSOAPBody(SOAPMessage
Impl.java:631)
at
org.drools.jax.soap.PreCxfTransportSoapProcessor.process(PreCxfTransp
ortSoapProcessor.java:42)
at
org.drools.camel.component.DroolsPolicy$DroolsProcess.process(DroolsP
olicy.java:341)
at
org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Processor
ToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelp
er.java:70)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delegat
eAsyncProcessor.java:98)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsy
ncProcessor.java:89)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelp
er.java:70)
