incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Neumeyer <leoneume...@gmail.com>
Subject Re: Dynamic processEvent method overloading
Date Thu, 13 Oct 2011 16:41:30 GMT
After some skype we converged to the following:

We support synchronous and asynchronous method triggers. The
synchronous trigger is activated when an input event arrives and the
asynchronous one is triggered by a timer.

Proposed solution:

* Synchronous methods:

Signature: processEvent(SomeEvent event)
Default behavior: trigger on every event
Configuration: configure triggers by Event type, synchronized with all
processEvent() and periodicTask() methods unless PE is annotated with
@ThreadSafe

* Asynchronous method:

Signature: periodicTask()
Default behavior: no trigger
Configuration: interval in time unit, synchronized with all
processEvent() methods unless PE is annotated with @ThreadSafe

-leo


On Thu, Oct 13, 2011 at 7:21 AM, Matthieu Morel
<matthieu.morel@gmail.com> wrote:
> On Wed, Oct 12, 2011 at 8:18 PM, Leo Neumeyer <leoneumeyer@gmail.com> wrote:
>
>>
>> ...
>>
>> >
>> >> 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
>>
>
> This is a part which is not clear to me. My understanding was that the
> output method might be triggered at periodic intervals, not the input
> processing method. You seem to want to mix both methods, which is a bit
> confusing to me. But it is also possible.
>
>
>
>>
>> We still need another method for periodic tasks, maybe a good name is
>> periodicTask()
>>
>
> is it a periodic task that we need (and we may), or is it a periodically
> invokable output method?
>
>
>
>> This method is synchronized with processEvent() (unless PS is
>> @ThreadSafe) and it doesn't need to pass an event (because it is
>> asynchronous).
>>
>> So it's not just removing processOutputEvent(), we need an additional
>> method for periodic tasks that is synchronized with processEvent().
>>
>
> That's the "output" method in the S4 paper, no?
>
>
>
> Matthieu
>



-- 

-leo

Mime
View raw message