I love this. Not much to add - it is an elegant solution, clean
implementation and it addresses a real need, especially during upgrades.
On Tue, Mar 20, 2018 at 2:49 PM, Ted Yu <yuzhih...@gmail.com> wrote:
> Thanks for the response.
>
> Assuming number of client versions is limited in a cluster, memory
> consumption is not a concern.
>
> Cheers
>
> On Tue, Mar 20, 2018 at 10:47 AM, Allen Wang <allenxw...@gmail.com> wrote:
>
> > Hi Ted,
> >
> > The additional hash map is very small, possibly a few KB. Each request
> type
> > ("produce", "fetch", etc.) will have such a map which have a few entries
> > depending on the client API versions the broker will encounter. So if
> > broker encounters two client versions for "produce", there will be two
> > entries in the map for "produce" requests mapping from version to meter.
> Of
> > course, hash map always have additional memory overhead.
> >
> > Thanks,
> > Allen
> >
> >
> > On Mon, Mar 19, 2018 at 3:49 PM, Ted Yu <yuzhih...@gmail.com> wrote:
> >
> > > bq. *additional hash lookup is needed when updating the metric to
> locate
> > > the metric *
> > >
> > > *Do you have estimate how much memory is needed for maintaining the
> hash
> > > map ?*
> > >
> > > *Thanks*
> > >
> > > On Mon, Mar 19, 2018 at 3:19 PM, Allen Wang <allenxw...@gmail.com>
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have created KIP-272: Add API version tag to broker's
> RequestsPerSec
> > > > metric.
> > > >
> > > > Here is the link to the KIP:
> > > >
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > 272%3A+Add+API+version+tag+to+broker%27s+RequestsPerSec+metric
> > > >
> > > > Looking forward to the discussion.
> > > >
> > > > Thanks,
> > > > Allen
> > > >
> > >
> >
>
--
*Gwen Shapira*
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter <https://twitter.com/ConfluentInc> | blog
<http://www.confluent.io/blog>
