Created a Jira for each: - https://issues.apache.org/jira/browse/KAFKA-6998 - https://issues.apache.org/jira/browse/KAFKA-6999
-Matthias On 5/11/18 10:06 AM, Guozhang Wang wrote: > 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.) >>> >>> >> > > >
signature.asc
Description: OpenPGP digital signature
