Re: Consulting ReadOnlyKeyValueStore from Processor can lead to deadlock

["Matthias J. Sax" <ma...@confluent.io>]

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 <yu...@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 <
>> sschlansker@opentable.com> wrote:
>>
>>>
>>>> On May 10, 2018, at 10:48 AM, Steven Schlansker <
>>> sschlansker@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.)
>>>
>>>
>>
> 
> 
>