Permission to contribute to Apache Kafka

Hi, As I now have my wiki Id: frouleau and my Jira Id: fred-ro, can I have the permission to contribute to KIP ? Regards,

Re: [VOTE] KIP-1036: Extend RecordDeserializationException exception

Hi, We can conclude with +4 binding and +3 non-binding votes. So it's adopted and I will propose it for the 3.8.0 release. Thank you everyone for your help and participation.

Re: [VOTE] KIP-1036: Extend RecordDeserializationException exception

Hi all, I will keep the vote open for a few more hours as I would like to propose the KIP for the next 3.8.0 release (deadline is the 15th May). Currently we have +4 binding and +3 non-binding. Thanks,

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi Sophie, I have updated the KIP and the PR. Regards,

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

ince we have to go through a deprecation cycle. So I'd prefer to > > just keep only the ByteBuffer versions (or only the byte[] -- don't > > personally care which of the two) > > > > One more small nit: since we're deprecating the old exception > constructor, > > can you list th

[VOTE] KIP-1036: Extend RecordDeserializationException exception

Hi all, As there is no more activity for a while on the discuss thread, I think we can start a vote. The KIP is available on https://cwiki.apache.org/confluence/display/KAFKA/KIP-1036%3A+Extend+RecordDeserializationException+exception If you have some feedback or suggestions, please participate

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi, I have updated the KIP now and the latest version of PR is available. About Kirk's questions: K11: Yes, both can have a deserialization exception but we deserialize the key first, so if an error occurs then, we do not try to deserialize the value. So the exception raised is always for key

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi Andrew, A1. I will change the order of arguments to match. A2 and A3, Yes the KIP is not updated yet as I do not have a wiki account. So I must rely on some help to do those changes, which add some delay. I will try to find someone available ASAP. A4. I had the same thought. Using keyBuffer

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi everyone, Thanks for all that valuable feedback. So we have a consensus not to use Record. I have updated to PR by creating 2 childs classes KeyDeserializationException and ValueDeserializationException. Those classes directly embed the required fields. I do not think a wrapper object would

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi, But I guess my main question is really about what metadata we really > want to add to `RecordDeserializationException`? `Record` expose all > kind of internal (serialization) metadata like `keySize()`, > `valueSize()` and many more. For the DLQ use-case it seems we don't > really want any of

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Thanks Sophie, I can write something in the KIP on how KStreams solves that issue, but as I can't create a Wiki account, I will have to find someone to do this on my behalf (if someone can work on solving that wiki account creation, it would be great). The biggest difference between Record and

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi Almog, I think you do not understand the behavior that was introduced with the KIP-334. When you have a DeserializationException, if you set the proper seek call to skip the faulty record, the next poll call will return the remaining records to process and not a new list of records. When the

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi everyone, I have made some changes to take in account comments. I have replaced the ConsumerRecord by Record. As it was not allowed by checkstyle, I have modified its configuration. I hope that's ok. I find this new version better. Thanks for your help. Regards, Fred

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi Kirk, I have made the test and I confirm that checkstyle is complaining (Disallowed import - org.apache.kafka.common.record.Record.) if I use Record class in the RecordDeserialisationException. An alternative might be to add key(), value(), headers() etc methods directly in the exception.

Re: [DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Thanks for your feedback. Kirk, that's a good point. I will check if there are other ways of raising an exception than the deserialisation itself. About Record, I agree I think it would be a better choice and my initial version was using it. But then I realised that this class might not be

[DISCUSS] KIP-1036: Extend RecordDeserializationException exception

Hi everyone, To make implementation of DLQ in consumer easier, I would like to add the raw ConsumerRecord into the RecordDeserializationException. Details are in KIP-1036 . Thanks for