Well, I am not totally sure if immutability is actually desired for `Headers`?
Consider the case when there is an application that just wants to add for example a tracing header field. It would just call `add()` on the consumer record's headers and pass the modified `Headers` object to the `ProducerRecord` constructor without the need to deep-copy (to be fair, there is no real deep copy as we would only copy some references). Or an application which multiple components and one component creates a `ProducerRecord`, some other component may or may not add some additional headers, and a third component does the actually send? I am wondering if this KIP might be a case of premature optimization? Is there an actual issue you have observed with mutable headers? -- It might also be worth to go back to the original headers KIP to see if there was a discussion about immutability and what the reasoning for the current design was? -Matthias On 8/18/20 7:42 PM, Chia-Ping Tsai wrote: >> If you create a new `ProducerRecord` you would not pass in a `Headers` >> object but a `Iterable<Header>`? >> >> And for `ConsumerRecord` you just get a `Headers` object back and don't >> need to worry about the concrete implementation? > > You are right. I'd give a bad case :( > > For another reason, could we avoid using a mutable object to be the response > type? ConsumerRecord and ProducerRecord have a good chance to be immutable if > we can remove setters from Headers. > > On 2020/08/18 20:42:59, "Matthias J. Sax" <mj...@apache.org> wrote: >> Thanks for the KIP. However, I am not sure for what use-case you would >> need to implement the `Headers` interface? >> >> If you create a new `ProducerRecord` you would not pass in a `Headers` >> object but a `Iterable<Header>`? >> >> And for `ConsumerRecord` you just get a `Headers` object back and don't >> need to worry about the concrete implementation? >> >> >> -Matthias >> >> >> On 8/18/20 3:39 AM, Chia-Ping Tsai wrote: >>> Hi everyone, >>> >>> I would like to start a discussion on KIP-658: >>> https://cwiki.apache.org/confluence/x/-DJ4CQ >>> >>> KIP-658 plans to deprecate all setters of Headers and provide default >>> implementation. The benefit of this KIP are shown below. >>> >>> 1. Users don't need to implement those setters which are not used by kafka. >>> 2. open a room to refactor Headers in next major (for example, a pojo >>> Headers) >>> >>> feedback is welcome!!! >>> >>> ---- >>> chia-ping >>> >> >>
signature.asc
Description: OpenPGP digital signature
