Re: [rules-users] Expiry of events not occurring for sliding window

2011-09-29 Thread cfuser
I've done a bit more looking -- based upon what I've read and what I've seen
via testing, you don't need to have a temporal constraint on a CE for it to
be expired, provided there is an explicit one declared.  Is that correct?

That said...

Ok, maybe there is a silly mistake here, but I'm seeing the following expire
and retract objects (note no temporal constraint)


imports

declare CheeseTime
   @role(event)
   @expires(10s)
   @timestamp(timeStamp)
end   


rule Print Objects
when
$m:Object( )
from entry-point stat-stream
then
logger.warn( CheeseTime-- );
logger.warn( --+$m);
end



(note the Object() ) but not this

(same declarations except replacing the rule)


rule Print CheeseTime
when
$m:CheeseTime()
from entry-point stat-stream
then
logger.warn( Object-- );
logger.warn( --+$m);
end




For CheeseTime


public class CheeseTime {

private String type;
private long cost;
private Date timeStamp;
  :
}



Clearly, I'm missing something...

--
View this message in context: 
http://drools.46999.n3.nabble.com/Expiry-of-events-not-occurring-for-sliding-window-tp3362402p3380503.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] CEP sliding window in the past

2011-09-23 Thread cfuser
I can (belatedly) confirm that this works for this instance.  We want to do
averages and other accumulations in the future, so it won't be as applicable
then.  

I looked at the source and it shouldn't be that difficult to implement that
offset, so when that time comes when we need those different accumulations,
I'll give a shot and see how it goes.  Thanks for the help.

--
View this message in context: 
http://drools.46999.n3.nabble.com/CEP-sliding-window-in-the-past-tp3314638p3362259.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] Expiry of events not occurring for sliding window

2011-09-23 Thread cfuser
I'll preface this by saying this may not be the correct way to do this, so
suggestions welcome...

For this example, the name can be something like 'collector1', 'collector2'. 
For each collector, there are normalized stats, like 'CPU', 'IO', etc.  

pre
// Imports and other stuff

declare InstanceHealth
   @role(event)
   @expires(10s)
   @timestamp(timeStamp)
end

rule Iostats above 90 over 5 seconds
when
$mih:InstanceHealth($id:id, $luid:name, $stat:stat )
from entry-point stat-stream
$measure : Number( doubleValue  90 )
from accumulate(
InstanceHealth( $inst:name==$luid, $value:value,
stat==$stat)
over window:time( 5s ) from entry-point stat-stream,
average($value))
then
logger.warn( Average-- );
logger.warn( $mih.hashCode() +  // +$stat + // +$id+ :
+$luid + == +$measure );
 
// doStuff based upon the name and stat 
end

rule Log instance
when
$m:InstanceHealth($id:id, $stat:stat, $inst:name, $v:value )
from entry-point stat-stream
then
logger.warn( Instance-- );
logger.warn( --+$inst+ == +$stat + value = +$v );

end
/pre

So the 'Iostats above 90 over 5 seconds' rule is trying to match up stats
with collectors so there are no cross-products  (stats aren't accumulated
across collectors and each stat type gets it's own evaluation).  This
actually seems to be working, except the InstanceHealth objects don't seem
to be being evicted and I'm apparently getting multiple activations (?). 
Note when I remove the line w/ the $mih binding, things get evicted fine but
I don't have access to the name, stat, etc.  TIA.


A snippet of a log (I can confirm that three different iostats were inserted
for collector2)

==[ObjectInsertedEventImpl:
getFactHandle()=1:19:1003982845:1003982845:19:stat-stream,
getObject()=com.poc.mediator.domain.InstanceHealth : null,
getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl@30a2268a,
getPropagationContext()=PropagationContextImpl [activeActivations=0,
dormantActivations=15, entryPoint=EntryPoint::stat-stream,
factHandle=1:19:1003982845:1003982845:19:stat-stream, leftTuple=null,
originOffset=-1, propagationNumber=13, rule=null, type=0]]
2011-09-23 11:35:16,004 [Rule-Execution-Thread] WARN  WorkingMemory  -
Average--
2011-09-23 11:35:16,004 [Rule-Execution-Thread] WARN  WorkingMemory  -
1302111244 // iostats // null : collector2 == 91.0
2011-09-23 11:35:16,004 [Rule-Execution-Thread] WARN  WorkingMemory  -
Average--
2011-09-23 11:35:16,004 [Rule-Execution-Thread] WARN  WorkingMemory  -
158787804 // iostats // null : collector2 == 91.0
2011-09-23 11:35:16,004 [Rule-Execution-Thread] WARN  WorkingMemory  -
Average--
2011-09-23 11:35:16,004 [Rule-Execution-Thread] WARN  WorkingMemory  -
1785305512 // iostats // null : collector2 == 91.0
==[ObjectInsertedEventImpl:
getFactHandle()=1:21:1340153218:1340153218:21:stat-stream,
getObject()=com.poc.mediator.domain.InstanceHealth : null,
getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl@30a2268a,
getPropagationContext()=PropagationContextImpl [activeActivations=0,
dormantActivations=20, entryPoint=EntryPoint::stat-stream,
factHandle=1:21:1340153218:1340153218:21:stat-stream, leftTuple=null,
originOffset=-1, propagationNumber=16, rule=null, type=0]]
2011-09-23 11:35:16,100 [Insertion Thread] INFO 
mediator.RulesExecutionService  - inserting
com.poc.mediator.domain.InstanceHealth : null...
2011-09-23 11:35:16,101 [Insertion Thread] WARN 
mediator.RulesExecutionService  -
lt;org.drools.event.rule.impl.ObjectInsertedEventImpl@1dddec9e
factHandle=1:21:1340153218:1340153218:21:stat-stream
object=com.poc.mediator.domain.InstanceHealth : null
kruntime=org.drools.impl.StatefulKnowledgeSessionImpl@30a2268a
propagationContext=PropagationContextImpl [activeActivations=0,
dormantActivations=20, entryPoint=EntryPoint::stat-stream,
factHandle=1:21:1340153218:1340153218:21:stat-stream, leftTuple=null,
originOffset=-1, propagationNumber=16, rule=null, type=0]gt;
2011-09-23 11:35:16,101 [Insertion Thread] INFO 
mediator.RulesExecutionService  - ...done inserting
lt;com.poc.mediator.domain.InstanceHealth@4fe11d82 timeStamp=Fri Sep 23
11:35:16 CDT 2011 stat=cpu value=88.0 id=null version=null
Instance=com.poc.mediator.domain.Instance : nullgt;
2011-09-23 11:35:16,108 [Insertion Thread] INFO 
mediator.RulesExecutionService  - inserting
com.poc.mediator.domain.InstanceHealth : null...
2011-09-23 11:35:16,109 [Insertion Thread] WARN 
mediator.RulesExecutionService  -
lt;org.drools.event.rule.impl.ObjectInsertedEventImpl@56300388
factHandle=1:23:1092542236:1092542236:23:stat-stream

Re: [rules-users] Expiry of events not occurring for sliding window

2011-09-23 Thread cfuser
Thanks for the quick turnaround.

Hmm...ok, I added a sliding window to the CE you called (5s), but still, no
expiry (and I removed the log instance to make sure there wasn't some
oddness there).  So, it seems there is there some implicit expiration that
is greater than my 10s that I declared--it's not obvious to me how to tell
what this is, however.

Looking at this a different way--to me the rules make sense for what I'm
trying to accomplish, but maybe as far as the syntax or best practice here,
there is a better way?  I looked at
http://drools.46999.n3.nabble.com/Accumulate-Temporal-Operators-td121073.html#a124161
and I can try injecting the results into another stream, however, it seems
that doesn't address my need for 'bucketing' items into a name:stat
relationship and comparing against my threshold.  

Thanks again.

--
View this message in context: 
http://drools.46999.n3.nabble.com/Expiry-of-events-not-occurring-for-sliding-window-tp3362402p3362683.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] CEP sliding window in the past

2011-09-06 Thread cfuser
Can you offset the sliding window functionality to look for a window in the
past?  What I'm trying to do is offset the window from 'now'.  E.g. 
Assuming it is 12:05 and I have been receiving objects for 5 minutes, I'm
trying to get this to sum received objects between 2 and 3 minutes ago.  

rule Accumulate attempts over 1 minute (window over time)
when
$measure : Number()
from accumulate( MyData( $m:measures[attempts],
objectType==climber )
over window:time( 2m, 3m ) from entry-point My Stream,
sum($m))

then
#
end 

Looking at the SlidingTimeWindow source code, it looks as though you can't
offset the window by a delay?  Is that accurate?  If you can't do that
directly via a sliding window, is there a way to work around this?

TIA.


--
View this message in context: 
http://drools.46999.n3.nabble.com/CEP-sliding-window-in-the-past-tp3314638p3314638.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