incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Neumeyer <>
Subject Re: Dynamic processEvent method overloading
Date Wed, 12 Oct 2011 18:18:47 GMT
see below.


> what is "timeout expired"? For now, outputs triggered by timers are handled
> by processOutputEvent(TimerEvent event)

I meant the output interval as defined in ProcessingElement


>> A few thoughts:
>> Input/Output names may not make a lot of sense any longer. What about
>> changing to the following:
>> processEvent(Event1 event) with any of the synchronous configurations.
>> timerTask()  called when there is a timer task configured.
>> The timer task needs to be synchronized with the processEvent method
>> (unless the PE has a @ThreadSafe annotation), we can keep the internal dummy
>> event to synchronize but call timerTask() without an Event instead. I'm sure
>> there are other ways of doing this.
>> Does this make sense? We need to think a bit.
> Indeed, we lose some consistency in the API by handling output triggers in 2
> different methods, depending on the trigger (event count based or timer
> based)
> The original design (as described in the S4 paper) uses a "processEvent"
> method for input events and an "output" method for triggered outputs. Why
> not just keep that design? For the dynamic overload dispatcher, that would
> just mean removing the code for "processOutputEvent".

Not sure I understand what you propose. I think we are saying the same:

the processEvent() method can be configured to be triggered:

- on every matching input event
- on every N matching input events
- on input event if time since last event is greater than delta

We still need another method for periodic tasks, maybe a good name is

This method is synchronized with processEvent() (unless PS is
@ThreadSafe) and it doesn't need to pass an event (because it is

So it's not just removing processOutputEvent(), we need an additional
method for periodic tasks that is synchronized with processEvent().
Makes sense?

> What do you think?
> Matthieu



View raw message