Hi Markus, Yes, I agree that storing activation records should be a separated discussion. Pipe activation records into logging system (elasticsearch, kibana) will be cool!
But I think I'm not asking these now though, however, thanks for pointing these out, looks interesting. I think I got some misunderstanding. Originally, I considered some edge cases once invoker got failed during responding back with active-ack, but there's no recovery/retry logic from now (therefore so-called best-effort). However, whether supporting stronger execution guarantee may not be discussed here now, but this indeed will be different mechanism if we bypassing Kafka or not. Thanks for answering me anyway, Tzuchiao On Tue, Jul 17, 2018 at 4:49 PM Markus Thoemmes <markus.thoem...@de.ibm.com> wrote: > Hi Tzu-Chiao, > > great questions although I'd relay those into a seperate discussion. The > design proposed does not intent to change the way we provide > oberservibility via persisting activation records. The controller takes > that responsibility in the design. > > It is fair to open a discussion on what our plans for the activation > record itself are though, in the future. There is a lot of work going on in > that area currently, with Vadim implementing user-facing metrics (which can > serve of part of what activation records do) and James implementing > different ActivationStores with the intention to eventually moving > activation records to the logging system. > > Another angle here is that both of these solutions drop persistence of the > activation result by default, since it is potentially a large blob. > Persisting logs into CouchDB doesn't really scale either so there are a > couple of LogStores to shift that burden away. What remains is largely a > small, bounded record of some metrics per activation. I'll be happy to see > a separate proposal + discussion on where we want to take this in the > future :) > > Cheers, > Markus > >
