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 t
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
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.
// Imports and other stuff
dec
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
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
