Hello Steven, thanks for pointing it out. I think both of the mentioned issues worth be improving:
1. The read-write lock documentation for caching enabled stores. 2. When CACHE_MAX_BYTES_BUFFERING_CONFIG is set to 0, we should automatically disable the dummy caching layer in all stores as it is not only non-necessary but also brings wasted CPUs (i.e. you are enforcing a flush on each put operation). Do you mind file a JIRA for both of them? And I'd appreciate if you are willing to tackle on 1) above :) Guozhang On Thu, May 10, 2018 at 7:21 PM, Ted Yu <yuzhih...@gmail.com> wrote: > bq. the docs and CachingKVS behavior could improve > > I would agree. > > Pointing out the usage of ReadWriteLock and mentioning the > withCachingDisabled() > method in doc would help other developers. > > On Thu, May 10, 2018 at 11:21 AM, Steven Schlansker < > sschlans...@opentable.com> wrote: > > > > > > On May 10, 2018, at 10:48 AM, Steven Schlansker < > > sschlans...@opentable.com> wrote: > > > > > > But it still remains -- when you go an read that ROKVS documentation, > it > > sure > > > doesn't prepare you to this possibility! And, it's a little > frustrating > > that > > > we have to have this 'caching' layer at all -- we already had to add > > > > > > // ensure KTable doesn't delay updates due to buffering in cache > > > kafkaStreamProps.put(StreamsConfig.CACHE_MAX_BYTES_ > BUFFERING_CONFIG, > > 0); > > > > Now that I've said this, it seems that since I last checked we got > > 'Materialized.withCachingDisabled'. > > I'll see if that does what I want... (I still think the docs and > > CachingKVS behavior could improve, though.) > > > > > -- -- Guozhang
