A fusion design question: I have events that represent intervals. Initially the intervals are open-ended (kind a like the current state of an entity). Other events are matched "during" the interval and correlated. At some point the interval will be closed (eg, a specific downtime interval is closed because the device is no online again). All the events in this system are immutable -- so if some property of an event changes, it is cloned and modified in working-memory. For the case of the interval events, initially the interval is inserted open-ended, and at some point later closed and then modified. This does not work with fusion however, since an event's duration is maintained by the fact-handle not the event itself. Hence a modify with a now closed interval (ie, a finite @duration) has no effect. I'm guessing the temporal values are maintained the handle to ensure stable values for the behaviors that trigger based on temporal values, which is reasonable. So I'm looking for alternative designs. Some are: 1) Modeled the intervals as begin/end events, but that gets messy real fast (have to correlate the begin/end events somehow, can't use evaluators like 'includes' or 'during', etc). 2) Retract the interval event when it is closed (this way closed intervals no longer correlate with other incoming events). But then we really have a manually maintained state machine using only facts, and there can be no reasoning over a series these interval events. (eg, 3 downtimes longer than 2 minutes in the last hour). Opinions? -barry -- View this message in context: http://n3.nabble.com/Fusion-and-open-ended-intervals-tp719076p719076.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

If I understand you correctly Edson, you have provided a better description to solution 1) in my post above. This works to a degree but leaves a bit to be desired. For example when correlating instant events as "during" the interval events (ie, startX, endX, eventX) those correlations cannot simply use "during", because there may be no eventX yet (ie, endX has not yet occurred). This requires patterns of the form: instant: InstantEvent beginX: BeginX (or (and instant after beginX not endX(id == beginX.id) instant is during eventX(id == beginX.id) Which like I said gets messy. Again, if the @timestamp and @duration were not stored in the fact handle and could be altered via a working-memory update then "instant is during eventX" would work in all instances. The trade off is that it would make the drools internals much more complex as behaviors scheduled based on @timestamp and @duration would need to be modified according on a wm.update, along with all race conditions that would entail. It could also be argued that modifying an event's timestamp smells for purity reasons. But that would depend the perspective you take. Some events unfold over time (hence the modeling construct of using startX, endX, eventX). So a counter argument might be that a CEP engine should have first class support events of this nature. -- View this message in context: http://n3.nabble.com/Fusion-and-open-ended-intervals-tp719076p721426.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

From: Barry Kaplan <groups1(a)memelet.com&gt; Subject: [rules-users] Fusion and open-ended intervals? To: rules-users(a)lists.jboss.org Date: Wednesday, April 14, 2010, 12:23 PM A fusion design question: I have events that represent intervals. Initially the intervals are open-ended (kind a like the current state of an entity). Other events are matched "during" the interval and correlated. At some point the interval will be closed (eg, a specific downtime interval is closed because the device is no online again). All the events in this system are immutable -- so if some property of an event changes, it is cloned and modified in working-memory. For the case of the interval events, initially the interval is inserted open-ended, and at some point later closed and then modified. This does not work with fusion however, since an event's duration is maintained by the fact-handle not the event itself. Hence a modify with a now closed interval (ie, a finite @duration) has no effect. I'm guessing the temporal values are maintained the handle to ensure stable values for the behaviors that trigger based on temporal values, which is reasonable. So I'm looking for alternative designs. Some are:   1) Modeled the intervals as begin/end events, but that gets messy real fast (have to correlate       the begin/end events somehow, can't use evaluators like 'includes' or 'during', etc).   2) Retract the interval event when it is closed (this way closed intervals no longer correlate       with other incoming events). But then we really have a manually maintained state machine       using only facts, and there can be no reasoning over a series these interval events.      (eg, 3 downtimes longer than 2 minutes in the last hour). Opinions? -barry -- View this message in context: http://n3.nabble.com/Fusion-and-open-ended-intervals-tp719076p719076.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users