incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Morel <>
Subject Re: Dynamic processEvent method overloading
Date Wed, 12 Oct 2011 11:42:16 GMT
On Tue, Oct 11, 2011 at 10:52 PM, Leo Neumeyer <>wrote:

> Matthieu,
> The dynamic overloading looks pretty good. Questions:
> The timer will dispatch with TimerEvent. So to implement timer, the PE
> needs a processOutputEvent(TimerEvent event) right?

Right now, this is how it is done. I simply adapted the existing API.
However, as you mention later in your email, we may go for a different
approach for output events.

> I think this is fine, to reuse code, one can simply call another method in
> the PE. We can have this method combined with a different one that is
> triggered on each input or every N inputs. Those will need to use the
> expected input event type.
> When the method event type is Event, then it accepts all the input events,
> right?

Yes, and it is called unless another more specialized method is a better
match for a given input event.

> What happens if you send CountEvent and have methods:
> processInputEvent(CountEvent event)
> processInputEvent(Event event)
> Which method gets dispatched? The more specific one?

Yes. (see also relevant javadoc for the `OverloadDispatcher interface)

> The semantics seem to be as follows:
> processInputEvent(Event1 event)  means dispatch on every input event of
> type Event1

yes, Event1 or subtype of Event1

> processOutputEvent(Event2 event)  means dispatch according to configuration
> (on every event, every N events, on event if timeout expired) where event is
> of type Event2.

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

> processOutputEvent(TimerEvent event) asynchronously with timer, dummy event
> is always of type TimerEvent

as it is now, yes

> 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

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".

What do you think?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message