Hi Gyula,
if you look at the internal API you'll notice that it is pretty much like
your second proposal. Just for reference, the interface is roughly this:
public interface InternalTimerService<N> {
long currentProcessingTime();
long currentWatermark();
void registerProcessingTimeTimer(N namespace, long time);
void deleteProcessingTimeTimer(N namespace, long time);
void registerEventTimeTimer(N namespace, long time);
void deleteEventTimeTimer(N namespace, long time);
}
that namespace bit can be anything for which you can provide a
TypeSerializer.
IMHO, this goes back a bit to the discussion about adding a low level
operator-like interface that allows pretty much anything a custom operator
can do but with a defined, stable interface. The internal operator
interface is somewhat in flux, still, so I wouldn't recommend people to use
it directly.
The only thing missing, really, from TimelyFlatMap is access to namespaces
for state and timers. With that, you could implement even the
WindowOperator as a TimelyFlatMap since I worked on abstracting everything
that it uses away behind interfaces that any operator can use. The last
pice, the generic timer API went in last, of course. :-)
Cheers,
Aljoscha
On Fri, 28 Oct 2016 at 16:55 Gyula Fóra <gyf...@apache.org> wrote:
> Hello,
>
> I was thinking about the methods provided by the timely functions and the
> timerservice and I am wondering if it makes sense to change them a little
> so they can cover a wider set of use case. Maybe I missed something
> completely obvious so please shoot me down in that case :)
>
> Currently the user gets a TimerService to register timers that will in the
> future call the onTimer method. It is not completely obvious to me how
> would I implement a function that needs to trigger two types of callbacks
> in the future. If I get only one onTimer method I should be able to pass in
> some sort of parameter or flag so I can branch in my onTimer
> implementation.
>
> As parameters are not supported I am left with states that are scoped to
> the keys which is also pretty useless if I want to trigger different timed
> actions for the same keys.
>
> I know this is quite tricky but I see some alternative options:
> - The register timer method returns a unique (per key) timer id, so we can
> associate state with this id to fetch info about the timer registered. (We
> could also remove timers with this id and maybe add methods to remove all
> for the current key)
> - Allow the users to pass a custom parameter when registering the
> callback, and the parameter would be passed to the onTimer method
> - Allow users to pass custom callback functions when registering the
> timers, but this would mean we have to support some sort of context for
> accessing the state (like the window context before)
> - We could go for an annotation based API like in beam but thats probably
> not good to mix in the current ones
>
> I personally prefer the first one.
>
> What do you think?
>
> Regards,
> Gyula
>
