I support exposing these stats, and I don't have a preference regarding where to put the method.
> I believe the implementation will be harder that way Would it be sufficient to make the field return Optional<ProducerStats> or to return `null`? I don't think we have defined a convention stating we prefer to wrap fields with `Optional`, but I think it'd be a reasonable use of the wrapper and it'd make it clear to users that the value might not be present. Thanks, Michael On Mon, Mar 6, 2023 at 10:24 AM Kai Levy <kl...@toasttab.com> wrote: > > I agree, adding it to the ConsumerStats interface makes more logical sense, > but I believe the implementation will be harder that way, since the > producers are lazily initialized. They won't be available when > ConsumerStats is created, and there isn't currently a way to access them > directly from the consumer. > > Kai > > On Sun, Mar 5, 2023 at 5:19 AM Asaf Mesika <asaf.mes...@gmail.com> wrote: > > > I would rather see them as attributes of ConsumerStats . > > Add > > > > ProducerStats deadLetterProducerStats; > > > > ProducerStats retryLetterProducerStats(); > > > > > > On Fri, Mar 3, 2023 at 2:54 AM Kai Levy <kl...@toasttab.com> wrote: > > > > > Hello! > > > > > > I created a new PIP because I discovered there's no way for a user to > > > access the metrics for a consumer's deadLetterProducer / > > > retryLetterProducer, since it is private to ConsumerImpl.java. I would > > like > > > to propose an API change that would expose those statistics. More details > > > on the github issue: > > > https://github.com/apache/pulsar/issues/19698 > > > > > > Thanks! > > > Kai > > > > >
