Also, the KIP doesn't describe the client-side experience Is a producer only expected to get the new API error in the response when the interceptor fails unexpectedly ? It looks otherwise that it is expected that records may get skipped or mutated without the producer metadata response noting this.
This is a significant difference from one of the other KIPs mentioned, where the intention was for a producer to receive PolicyFailed exceptions. This should be part of the KIP, IMHO On Tue, 21 Feb 2023 at 13:53, Edoardo Comar <edoardli...@gmail.com> wrote: > Hi David > thanks for the KIP. > > Two initial observations from me. > > I think the Rejected Alternatives section could compare your proposal to > the prior art that you rightly mention initially. > > Also, the Java interface could extend Kafka's own Configurable. > This allows an implementation to get hold of the static properties with > which a broker is started. > In practice, that's a way to get hold of configuration entries for a > plug-in class, > as you can add entries to a broker server.properties that get ignored by > the broker but passed on to plugins. > > cheers, > Edoardo > > On Thu, 9 Feb 2023 at 19:28, David Mariassy <david.maria...@gmail.com> > wrote: > >> Hi everyone, >> >> I'd like to get a discussion going for KIP-905 >> < >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-905%3A+Broker+interceptors >> >, >> which proposes the addition of broker interceptors to the stack. >> >> The KIP contains the motivation, and lists the new public interfaces that >> this change would entail. Since my company had its quarterly hack days >> this >> week, I also took the liberty to throw together a first prototype of the >> proposed new feature here: https://github.com/apache/kafka/pull/13224. >> >> Looking forward to the group's feedback! >> >> Thanks, >> David >> >
