Hi Becket, Comments inline.
On Sat, Feb 25, 2017 at 10:33 PM, Becket Qin <becket....@gmail.com> wrote: > > 1. Regarding the mutability. > > I think it would be a big convenience to have headers mutable during > certain stage in the message life cycle for the use cases you mentioned. I > agree there is a material benefit especially given that we may have to > modify the headers for each message. > > That said, I also think it is fair to say that in the producer, in order to > guarantee the correctness of the entire logic, it is necessary that at some > point we need to make producer record immutable. For example we probably > don't want to see that users accidentally updated the headers when the > producer is doing the serialization or compression. > > Given that, would it be possible to make Headers to be able to switch from > mutable to immutable? We have done this for the Batch in the producer. For > example, initially the headers are mutable, but after it has gone through > all the interceptors, we can call Headers.close() to make it immutable > afterwards. > The difference is that the batch is an internal class that is not exposed to users. Can you please explain what happens if a user tries to send the same ProducerRecord twice? Would an interceptor fail when trying to mutate the header that is now closed? Or did you have something else in mind? Thanks, Ismael
