If you build a store and enable caching, you get the KTable behavior out
of the box. No need to write any custom code in the processor itself.


StoreBuilder builder =
Stores.keyValueStoreBuilder(...).withCachingEnabled();

topology.addStateStore(builder, ...)



-Matthias

On 1/31/18 6:19 PM, Dmitry Minkovsky wrote:
> I am writing a processor and I want its stores to behave like KTables: For
> consistency, I don't want to forward values until the stores have been
> flushed.
> 
> I am looking at `ForwardingCacheFlushListener` and see that it is using
> `InternalProcessorContext` to change the current node, perform a forward,
> and then set the node back.
> 
> Now, I could do the same (`InternalProcessorContext` is public), but:
> should I? I'm not well versed in the internals, so I am wondering what the
> ramifications of this might be. Is this okay to do? Should I?
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to