I am implementing a bounded session window but I require to short circuit the session if the session length ( in count of events or time ) go beyond a configured limit , a very reasonable scenario ( bot etc ) . I am using the approach as listed. I am not sure though if the Window itself is being terminated and if that is even feasible. Any other approach or advise ?
public class BoundedEventTimeTrigger extends Trigger<Object, TimeWindow> { } |
It might be more complicated if you want to take into account events coming in out of order. For example you limit length of window to 5 and you get the following events: 1 2 3 4 6 7 8 5 Do you want to emit windows: [1 2 3 4 5] (length limit exceeded) + [6 7 8] ? Or are you fine with interleaving windows in case of out of order: [1 2 3 4 6] + [5 7 8] If the latter one, some custom Trigger should be enough for you. If not, you would need to implement hypothetical MergingAndSplitableWindowAssigner, that after encountering late event “5” could split previously created windows. Unfortunately such feature is not supported by a WindowOperator, so you would have to implement your own operator for this. Regardless of your option remember to write some integration tests: Piotrek
|
Thanks you for the response. I would not mind the second scenario as in a second window, which your illustration suggests with a custom trigger approach, I am not certain though that triggers define the lifecycle of a window, as in a trigger firing does not necessarily imply a Garbage Collectable Window. It should be GCed only after the watermark exceeds a hypothetically ever increasing window leading boundary by a lag. In a some case that might never happen as in the leading boundary is forever increasing. We may decide to fire_and_purge. fire etc but the window remains live. Or did I get that part wrong ? Vishal. On Thu, Nov 9, 2017 at 8:24 AM, Piotr Nowojski <[hidden email]> wrote:
|
Indeed you are unfortunately right. Triggers do not define/control lifecycle of the window, so it could happen that each new event is constantly pushing the leading boundary of the window, while your custom trigger is constantly triggering and purging this single EVENT (because exceeded max window length). So probably my example of events: 1 2 3 4 6 7 8 5 Would result in following fired windows: [1 2 3 4 6] (window time from 1 to 6) + [7] - (window time from 1 to 7) + [8] - (window time from 1 to 8) + [5] - (window time from 1 to 8) I’m not sure if you can walk around this issue. You would have to either implement your custom WindowOperator that behaves differently or you could copy the code and add new TriggerResult - FIRE_PURGE_AND_DROP_WINDOW. The later one maybe could be contributed back into Flink (should be discussed in some ticket before). Piotrek
|
Free forum by Nabble | Edit this page |