kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guozhang Wang <wangg...@gmail.com>
Subject Re: Consulting ReadOnlyKeyValueStore from Processor can lead to deadlock
Date Fri, 11 May 2018 17:06:30 GMT
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 <yuzhihong@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.)
> >
> >
>



-- 
-- Guozhang

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message