KIP Creation permission
Hi Admin, Could you please provide me Permissions to create a KIP. Thanks Renuka M
Re: KIP Creation permission
renumetuk...@gmail.com Thanks Renuka M On Wed, Aug 21, 2019 at 5:28 PM Matthias J. Sax wrote: > What is your wiki id? > > On 8/21/19 3:46 PM, Renuka M wrote: > > Hi Admin, > > > > Could you please provide me Permissions to create a KIP. > > > > Thanks > > Renuka M > > > >
Re: KIP Creation permission
Yes.. username: rmetukuru Email: renumetuk...@gmail.com Thanks Renuka M On Wed, Aug 21, 2019 at 5:58 PM Matthias J. Sax wrote: > There is no user with this name. > > Did you create an account? If yes, we need your wiki id (ie, user name) > to grant permissions. > > > -Matthias > > On 8/21/19 5:51 PM, Renuka M wrote: > > renumetuk...@gmail.com > > > > Thanks > > Renuka M > > > > On Wed, Aug 21, 2019 at 5:28 PM Matthias J. Sax > > wrote: > > > >> What is your wiki id? > >> > >> On 8/21/19 3:46 PM, Renuka M wrote: > >>> Hi Admin, > >>> > >>> Could you please provide me Permissions to create a KIP. > >>> > >>> Thanks > >>> Renuka M > >>> > >> > >> > > > >
[ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi All, I am starting this thread to discuss https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData . Please provide the feedback. Thanks Renuka M
[DISCUSS] KIP-512:Adding headers to RecordMetaData
Hi All, I am starting this thread to discuss https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData . Please provide the feedback. Thanks Renuka M >
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi Gwen, 1.We are not doing any changes on the broker side. This change is only on Kafka clients library. 2. RecordMetaData is created by client library while appending record to ProducerBatch where offset alone returned by broker. Here we are adding headers to RecordMetaData while creating FutureRecordMetaData to create context between record and its metadata. I have updated the snippet in KIP proposed changes in step 3. 3. As we mentioned in alternatives, client side we can link record and its metadata using callback, but Interceptors having same RecordMetadata will not have context on for which record this MetaData belongs to. To fill that Gap, we are proposing these changes. Please let us know if we are not clear. Thanks Renuka M On Fri, Aug 23, 2019 at 7:08 PM Gwen Shapira wrote: > I am afraid I don't understand the proposal. The RecordMetadata is > information returned from the broker regarding the record. The > producer already has the record (including the headers), so why would > the broker need to send the headers back as part of the metadata? > > On Fri, Aug 23, 2019 at 4:22 PM Renuka M wrote: > > > > Hi All, > > > > I am starting this thread to discuss > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData > > . > > > > Please provide the feedback. > > > > Thanks > > Renuka M > > > > -- > Gwen Shapira > Product Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog >
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi Eric, We thought about that but we didn't find the strong enough reason for having record itself in Acknowledgement. Headers are supposed to carry metadata and that is the reason headers are added to producer/consumer records. Also we feel having headers information in record metadata is good enough to bridge the gap and link the record to its metadata. Its simple change since we are not adding any new method signatures. Adding new method signatures requires adoption and deprecation of old ones to reduce duplication. If we get enough votes on adding new method signature, we are open to add it. Thanks Renuka M On Mon, Aug 26, 2019 at 10:54 AM Eric Azama wrote: > Have you considered adding a new onAcknowledgement method to the > ProducerInterceptor with the signature onAcknowledgement(RecordMetadata > metadata, Exception exception, ProducerRecord record)? I would also > consider adding this to Producer Callbacks as well, since linking a > Callback to a specific record currently requires creating a new Callback > for every ProducerRecord sent. > > This seems like a more robust strategy compared to using Headers. Headers > don't necessarily contain anything that connects them to the original > ProducerRecord, and forcibly including information in the Headers seems > like unnecessary bloat. If your goal is to link a RecordMetadata to a > specific ProducerRecord, it seems simpler to make sure the original > ProducerRecord is accessible at the same time as the RecordMetadata > > On Mon, Aug 26, 2019 at 10:26 AM Renuka M wrote: > > > Hi Gwen, > > > > 1.We are not doing any changes on the broker side. This change is only on > > Kafka clients library. > > 2. RecordMetaData is created by client library while appending record to > > ProducerBatch where offset alone returned by broker. Here we are adding > > headers to RecordMetaData while creating FutureRecordMetaData to create > > context between record and its metadata. I have updated the snippet in > KIP > > proposed changes in step 3. > > 3. As we mentioned in alternatives, client side we can link record and > its > > metadata using callback, but Interceptors having same RecordMetadata will > > not have context on for which record this MetaData belongs to. To fill > that > > Gap, we are proposing these changes. > > Please let us know if we are not clear. > > > > Thanks > > Renuka M > > > > > > > > > > On Fri, Aug 23, 2019 at 7:08 PM Gwen Shapira wrote: > > > > > I am afraid I don't understand the proposal. The RecordMetadata is > > > information returned from the broker regarding the record. The > > > producer already has the record (including the headers), so why would > > > the broker need to send the headers back as part of the metadata? > > > > > > On Fri, Aug 23, 2019 at 4:22 PM Renuka M > wrote: > > > > > > > > Hi All, > > > > > > > > I am starting this thread to discuss > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData > > > > . > > > > > > > > Please provide the feedback. > > > > > > > > Thanks > > > > Renuka M > > > > > > > > > > > > -- > > > Gwen Shapira > > > Product Manager | Confluent > > > 650.450.2760 | @gwenshap > > > Follow us: Twitter | blog > > > > > >
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi Gwen/Team Can you please review the KIP. Hope we have clarified the question you have regarding proposal. Thanks Renuka M On Mon, Aug 26, 2019 at 3:35 PM Renuka M wrote: > Hi Eric, > > We thought about that but we didn't find the strong enough reason for > having record itself in Acknowledgement. > Headers are supposed to carry metadata and that is the reason headers are > added to producer/consumer records. > Also we feel having headers information in record metadata is good enough > to bridge the gap and link the record to its metadata. > Its simple change since we are not adding any new method signatures. > Adding new method signatures requires adoption and deprecation of old ones > to reduce duplication. > If we get enough votes on adding new method signature, we are open to add > it. > > Thanks > Renuka M > > On Mon, Aug 26, 2019 at 10:54 AM Eric Azama wrote: > >> Have you considered adding a new onAcknowledgement method to the >> ProducerInterceptor with the signature onAcknowledgement(RecordMetadata >> metadata, Exception exception, ProducerRecord record)? I would also >> consider adding this to Producer Callbacks as well, since linking a >> Callback to a specific record currently requires creating a new Callback >> for every ProducerRecord sent. >> >> This seems like a more robust strategy compared to using Headers. Headers >> don't necessarily contain anything that connects them to the original >> ProducerRecord, and forcibly including information in the Headers seems >> like unnecessary bloat. If your goal is to link a RecordMetadata to a >> specific ProducerRecord, it seems simpler to make sure the original >> ProducerRecord is accessible at the same time as the RecordMetadata >> >> On Mon, Aug 26, 2019 at 10:26 AM Renuka M wrote: >> >> > Hi Gwen, >> > >> > 1.We are not doing any changes on the broker side. This change is only >> on >> > Kafka clients library. >> > 2. RecordMetaData is created by client library while appending record to >> > ProducerBatch where offset alone returned by broker. Here we are adding >> > headers to RecordMetaData while creating FutureRecordMetaData to create >> > context between record and its metadata. I have updated the snippet in >> KIP >> > proposed changes in step 3. >> > 3. As we mentioned in alternatives, client side we can link record and >> its >> > metadata using callback, but Interceptors having same RecordMetadata >> will >> > not have context on for which record this MetaData belongs to. To fill >> that >> > Gap, we are proposing these changes. >> > Please let us know if we are not clear. >> > >> > Thanks >> > Renuka M >> > >> > >> > >> > >> > On Fri, Aug 23, 2019 at 7:08 PM Gwen Shapira wrote: >> > >> > > I am afraid I don't understand the proposal. The RecordMetadata is >> > > information returned from the broker regarding the record. The >> > > producer already has the record (including the headers), so why would >> > > the broker need to send the headers back as part of the metadata? >> > > >> > > On Fri, Aug 23, 2019 at 4:22 PM Renuka M >> wrote: >> > > > >> > > > Hi All, >> > > > >> > > > I am starting this thread to discuss >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData >> > > > . >> > > > >> > > > Please provide the feedback. >> > > > >> > > > Thanks >> > > > Renuka M >> > > >> > > >> > > >> > > -- >> > > Gwen Shapira >> > > Product Manager | Confluent >> > > 650.450.2760 | @gwenshap >> > > Follow us: Twitter | blog >> > > >> > >> >
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi Colin,
yes we agree but RecordMetadata in Interceptors and callbacks will not
have headers which gives context on for which record this MetaData belongs
to. To fill that Gap, we are proposing these changes.
Thanks
Renuka M
On Thu, Aug 29, 2019 at 10:20 AM Colin McCabe wrote:
> As Gwen commented earlier, the client already has the record that it sent,
> including all the headers.
>
> >
> > Future future = producer.send(myRecord, null);
> > future.get();
> > System.out.println("I sent myRecord with headers " + myRecord.headers());
> >
>
> best,
> Colin
>
>
> On Tue, Aug 27, 2019, at 17:06, Renuka M wrote:
> > Hi Gwen/Team
> >
> > Can you please review the KIP. Hope we have clarified the question you
> have
> > regarding proposal.
> >
> > Thanks
> > Renuka M
> >
> > On Mon, Aug 26, 2019 at 3:35 PM Renuka M wrote:
> >
> > > Hi Eric,
> > >
> > > We thought about that but we didn't find the strong enough reason for
> > > having record itself in Acknowledgement.
> > > Headers are supposed to carry metadata and that is the reason headers
> are
> > > added to producer/consumer records.
> > > Also we feel having headers information in record metadata is good
> enough
> > > to bridge the gap and link the record to its metadata.
> > > Its simple change since we are not adding any new method signatures.
> > > Adding new method signatures requires adoption and deprecation of old
> ones
> > > to reduce duplication.
> > > If we get enough votes on adding new method signature, we are open to
> add
> > > it.
> > >
> > > Thanks
> > > Renuka M
> > >
> > > On Mon, Aug 26, 2019 at 10:54 AM Eric Azama
> wrote:
> > >
> > >> Have you considered adding a new onAcknowledgement method to the
> > >> ProducerInterceptor with the signature
> onAcknowledgement(RecordMetadata
> > >> metadata, Exception exception, ProducerRecord record)? I would also
> > >> consider adding this to Producer Callbacks as well, since linking a
> > >> Callback to a specific record currently requires creating a new
> Callback
> > >> for every ProducerRecord sent.
> > >>
> > >> This seems like a more robust strategy compared to using Headers.
> Headers
> > >> don't necessarily contain anything that connects them to the original
> > >> ProducerRecord, and forcibly including information in the Headers
> seems
> > >> like unnecessary bloat. If your goal is to link a RecordMetadata to a
> > >> specific ProducerRecord, it seems simpler to make sure the original
> > >> ProducerRecord is accessible at the same time as the RecordMetadata
> > >>
> > >> On Mon, Aug 26, 2019 at 10:26 AM Renuka M
> wrote:
> > >>
> > >> > Hi Gwen,
> > >> >
> > >> > 1.We are not doing any changes on the broker side. This change is
> only
> > >> on
> > >> > Kafka clients library.
> > >> > 2. RecordMetaData is created by client library while appending
> record to
> > >> > ProducerBatch where offset alone returned by broker. Here we are
> adding
> > >> > headers to RecordMetaData while creating FutureRecordMetaData to
> create
> > >> > context between record and its metadata. I have updated the snippet
> in
> > >> KIP
> > >> > proposed changes in step 3.
> > >> > 3. As we mentioned in alternatives, client side we can link record
> and
> > >> its
> > >> > metadata using callback, but Interceptors having same RecordMetadata
> > >> will
> > >> > not have context on for which record this MetaData belongs to. To
> fill
> > >> that
> > >> > Gap, we are proposing these changes.
> > >> > Please let us know if we are not clear.
> > >> >
> > >> > Thanks
> > >> > Renuka M
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Aug 23, 2019 at 7:08 PM Gwen Shapira
> wrote:
> > >> >
> > >> > > I am afraid I don't understand the proposal. The RecordMetadata is
> > >> > > information returned from the broker regarding the record. The
> > >> > > producer already has the record (including the headers), so why
> would
> > >> > > the broker need to send the headers back as part of the metadata?
> > >> > >
> > >> > > On Fri, Aug 23, 2019 at 4:22 PM Renuka M
> > >> wrote:
> > >> > > >
> > >> > > > Hi All,
> > >> > > >
> > >> > > > I am starting this thread to discuss
> > >> > > >
> > >> > >
> > >> >
> > >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData
> > >> > > > .
> > >> > > >
> > >> > > > Please provide the feedback.
> > >> > > >
> > >> > > > Thanks
> > >> > > > Renuka M
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Gwen Shapira
> > >> > > Product Manager | Confluent
> > >> > > 650.450.2760 | @gwenshap
> > >> > > Follow us: Twitter | blog
> > >> > >
> > >> >
> > >>
> > >
> >
>
[VOTE] KIP-512:Adding headers to RecordMetaData
Hi All, After good discussion for KIP-512 https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData, am starting thread for voting. Thanks Renuka M
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi All,
Could you please take a look and let us know what you think on KIP-512 --
adding record headers to RecordMetaData.
Since headers also provides metadata about the record, adding these
to RecordMetaData, will allow to link record to its acknowledgement in
Interceptors.
The message tracing solutions like inca -
https://medium.com/@NetflixTechBlog/inca-message-tracing-and-loss-detection-for-streaming-data-netflix-de4836fc38c9
using producer callback to link records to its acknowledgement.
If we have headers info as part of RecordMetaData, we can capture the
record tracking in ProducerInterceptors itself.
This is what we are trying to solve.
Thanks
Renuka M
On Thu, Aug 29, 2019 at 10:49 AM Renuka M wrote:
> Hi Colin,
>
> yes we agree but RecordMetadata in Interceptors and callbacks will not
> have headers which gives context on for which record this MetaData belongs
> to. To fill that Gap, we are proposing these changes.
>
>
> Thanks
> Renuka M
>
> On Thu, Aug 29, 2019 at 10:20 AM Colin McCabe wrote:
>
>> As Gwen commented earlier, the client already has the record that it
>> sent, including all the headers.
>>
>> >
>> > Future future = producer.send(myRecord, null);
>> > future.get();
>> > System.out.println("I sent myRecord with headers " +
>> myRecord.headers());
>> >
>>
>> best,
>> Colin
>>
>>
>> On Tue, Aug 27, 2019, at 17:06, Renuka M wrote:
>> > Hi Gwen/Team
>> >
>> > Can you please review the KIP. Hope we have clarified the question you
>> have
>> > regarding proposal.
>> >
>> > Thanks
>> > Renuka M
>> >
>> > On Mon, Aug 26, 2019 at 3:35 PM Renuka M
>> wrote:
>> >
>> > > Hi Eric,
>> > >
>> > > We thought about that but we didn't find the strong enough reason for
>> > > having record itself in Acknowledgement.
>> > > Headers are supposed to carry metadata and that is the reason headers
>> are
>> > > added to producer/consumer records.
>> > > Also we feel having headers information in record metadata is good
>> enough
>> > > to bridge the gap and link the record to its metadata.
>> > > Its simple change since we are not adding any new method signatures.
>> > > Adding new method signatures requires adoption and deprecation of old
>> ones
>> > > to reduce duplication.
>> > > If we get enough votes on adding new method signature, we are open to
>> add
>> > > it.
>> > >
>> > > Thanks
>> > > Renuka M
>> > >
>> > > On Mon, Aug 26, 2019 at 10:54 AM Eric Azama
>> wrote:
>> > >
>> > >> Have you considered adding a new onAcknowledgement method to the
>> > >> ProducerInterceptor with the signature
>> onAcknowledgement(RecordMetadata
>> > >> metadata, Exception exception, ProducerRecord record)? I would also
>> > >> consider adding this to Producer Callbacks as well, since linking a
>> > >> Callback to a specific record currently requires creating a new
>> Callback
>> > >> for every ProducerRecord sent.
>> > >>
>> > >> This seems like a more robust strategy compared to using Headers.
>> Headers
>> > >> don't necessarily contain anything that connects them to the original
>> > >> ProducerRecord, and forcibly including information in the Headers
>> seems
>> > >> like unnecessary bloat. If your goal is to link a RecordMetadata to a
>> > >> specific ProducerRecord, it seems simpler to make sure the original
>> > >> ProducerRecord is accessible at the same time as the RecordMetadata
>> > >>
>> > >> On Mon, Aug 26, 2019 at 10:26 AM Renuka M
>> wrote:
>> > >>
>> > >> > Hi Gwen,
>> > >> >
>> > >> > 1.We are not doing any changes on the broker side. This change is
>> only
>> > >> on
>> > >> > Kafka clients library.
>> > >> > 2. RecordMetaData is created by client library while appending
>> record to
>> > >> > ProducerBatch where offset alone returned by broker. Here we are
>> adding
>> > >> > headers to RecordMetaData while creating FutureRecordMetaData to
>> create
>> > >> > context between record and its metadata. I have updated the
>> snippet in
>> > >> KIP
>> > >> > proposed changes in step 3.
>&g
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Bumping this in the hope I can get more feedback and/or votes.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData
Thanks,
Renuka M
On Mon, Sep 9, 2019 at 2:41 PM Renuka M wrote:
>
> Hi All,
>
> Could you please take a look and let us know what you think on KIP-512 --
> adding record headers to RecordMetaData.
> Since headers also provides metadata about the record, adding these
> to RecordMetaData, will allow to link record to its acknowledgement in
> Interceptors.
>
> The message tracing solutions like inca -
> https://medium.com/@NetflixTechBlog/inca-message-tracing-and-loss-detection-for-streaming-data-netflix-de4836fc38c9
> using producer callback to link records to its acknowledgement.
> If we have headers info as part of RecordMetaData, we can capture the
> record tracking in ProducerInterceptors itself.
>
> This is what we are trying to solve.
>
> Thanks
> Renuka M
>
>
>
>
>
> On Thu, Aug 29, 2019 at 10:49 AM Renuka M wrote:
>
>> Hi Colin,
>>
>> yes we agree but RecordMetadata in Interceptors and callbacks will not
>> have headers which gives context on for which record this MetaData belongs
>> to. To fill that Gap, we are proposing these changes.
>>
>>
>> Thanks
>> Renuka M
>>
>> On Thu, Aug 29, 2019 at 10:20 AM Colin McCabe wrote:
>>
>>> As Gwen commented earlier, the client already has the record that it
>>> sent, including all the headers.
>>>
>>> >
>>> > Future future = producer.send(myRecord, null);
>>> > future.get();
>>> > System.out.println("I sent myRecord with headers " +
>>> myRecord.headers());
>>> >
>>>
>>> best,
>>> Colin
>>>
>>>
>>> On Tue, Aug 27, 2019, at 17:06, Renuka M wrote:
>>> > Hi Gwen/Team
>>> >
>>> > Can you please review the KIP. Hope we have clarified the question you
>>> have
>>> > regarding proposal.
>>> >
>>> > Thanks
>>> > Renuka M
>>> >
>>> > On Mon, Aug 26, 2019 at 3:35 PM Renuka M
>>> wrote:
>>> >
>>> > > Hi Eric,
>>> > >
>>> > > We thought about that but we didn't find the strong enough reason
>>> for
>>> > > having record itself in Acknowledgement.
>>> > > Headers are supposed to carry metadata and that is the reason
>>> headers are
>>> > > added to producer/consumer records.
>>> > > Also we feel having headers information in record metadata is good
>>> enough
>>> > > to bridge the gap and link the record to its metadata.
>>> > > Its simple change since we are not adding any new method signatures.
>>> > > Adding new method signatures requires adoption and deprecation of
>>> old ones
>>> > > to reduce duplication.
>>> > > If we get enough votes on adding new method signature, we are open
>>> to add
>>> > > it.
>>> > >
>>> > > Thanks
>>> > > Renuka M
>>> > >
>>> > > On Mon, Aug 26, 2019 at 10:54 AM Eric Azama
>>> wrote:
>>> > >
>>> > >> Have you considered adding a new onAcknowledgement method to the
>>> > >> ProducerInterceptor with the signature
>>> onAcknowledgement(RecordMetadata
>>> > >> metadata, Exception exception, ProducerRecord record)? I would also
>>> > >> consider adding this to Producer Callbacks as well, since linking a
>>> > >> Callback to a specific record currently requires creating a new
>>> Callback
>>> > >> for every ProducerRecord sent.
>>> > >>
>>> > >> This seems like a more robust strategy compared to using Headers.
>>> Headers
>>> > >> don't necessarily contain anything that connects them to the
>>> original
>>> > >> ProducerRecord, and forcibly including information in the Headers
>>> seems
>>> > >> like unnecessary bloat. If your goal is to link a RecordMetadata to
>>> a
>>> > >> specific ProducerRecord, it seems simpler to make sure the original
>>> > >> ProducerRecord is accessible at the same time as the RecordMetadata
>>> > >>
>>> > >> On Mon, Aug 26, 2019 at 10:26 AM Renuka M
>>> wrote:
>>> > >>
>>> > >> > Hi Gwen,
>
Re: [ DISCUSS ] KIP-512:Adding headers to RecordMetaData
Hi All,
The motivation behind this KIP is have info about record in
ProducerInterceptor.onAcknowledgement(..), so that we can link record to
its metadata which is missing now. Initially we proposed to add headers to
RecordMetadata, so that we can link record to its metadata.
After thinking little bit more about it, we thought adding a record itself
to ProducerInterceptor.onAcknowledgement(..) makes sense since we can have
all data to link record to its metadata in Interceptors.
*public interface ProducerInterceptor extends Configurable *{
*@Deprecated public void onAcknowledgement(RecordMetadata metadata,
Exception exception); public default void
onAcknowledgement(RecordMetadata metadata, Exception exception,
ProducerRecord record){ onAcknowledgement(metadata, exception);
}*
}
we will not be adding new method to Callback which has same method
signature, since in callback the record information is already available
to link.
Please let us know your thoughts on this? If its makes sense, we will drop
original plan of adding headers to metadata, instead we can add an
overloaded onAcknowledgement(...) method to ProducerInterceptor with record
itself.
By providing above default implementation, we will have backward
compatibility, at the same time we can have deprecation plan for existing
method.
Thanks
Renuka M
On Thu, Sep 12, 2019 at 12:22 PM Renuka M wrote:
> Bumping this in the hope I can get more feedback and/or votes.
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-512%3AAdding+headers+to+RecordMetaData
>
> Thanks,
> Renuka M
>
> On Mon, Sep 9, 2019 at 2:41 PM Renuka M wrote:
>
>>
>> Hi All,
>>
>> Could you please take a look and let us know what you think on KIP-512 --
>> adding record headers to RecordMetaData.
>> Since headers also provides metadata about the record, adding these
>> to RecordMetaData, will allow to link record to its acknowledgement in
>> Interceptors.
>>
>> The message tracing solutions like inca -
>> https://medium.com/@NetflixTechBlog/inca-message-tracing-and-loss-detection-for-streaming-data-netflix-de4836fc38c9
>> using producer callback to link records to its acknowledgement.
>> If we have headers info as part of RecordMetaData, we can capture the
>> record tracking in ProducerInterceptors itself.
>>
>> This is what we are trying to solve.
>>
>> Thanks
>> Renuka M
>>
>>
>>
>>
>>
>> On Thu, Aug 29, 2019 at 10:49 AM Renuka M wrote:
>>
>>> Hi Colin,
>>>
>>> yes we agree but RecordMetadata in Interceptors and callbacks will not
>>> have headers which gives context on for which record this MetaData belongs
>>> to. To fill that Gap, we are proposing these changes.
>>>
>>>
>>> Thanks
>>> Renuka M
>>>
>>> On Thu, Aug 29, 2019 at 10:20 AM Colin McCabe
>>> wrote:
>>>
>>>> As Gwen commented earlier, the client already has the record that it
>>>> sent, including all the headers.
>>>>
>>>> >
>>>> > Future future = producer.send(myRecord, null);
>>>> > future.get();
>>>> > System.out.println("I sent myRecord with headers " +
>>>> myRecord.headers());
>>>> >
>>>>
>>>> best,
>>>> Colin
>>>>
>>>>
>>>> On Tue, Aug 27, 2019, at 17:06, Renuka M wrote:
>>>> > Hi Gwen/Team
>>>> >
>>>> > Can you please review the KIP. Hope we have clarified the question
>>>> you have
>>>> > regarding proposal.
>>>> >
>>>> > Thanks
>>>> > Renuka M
>>>> >
>>>> > On Mon, Aug 26, 2019 at 3:35 PM Renuka M
>>>> wrote:
>>>> >
>>>> > > Hi Eric,
>>>> > >
>>>> > > We thought about that but we didn't find the strong enough reason
>>>> for
>>>> > > having record itself in Acknowledgement.
>>>> > > Headers are supposed to carry metadata and that is the reason
>>>> headers are
>>>> > > added to producer/consumer records.
>>>> > > Also we feel having headers information in record metadata is good
>>>> enough
>>>> > > to bridge the gap and link the record to its metadata.
>>>> > > Its simple change since we are not adding any new method signatures.
>>>> > > Adding new method signatures requires adoption and deprecation of
>>>> old ones
>>>> > > to reduce duplication.
>
Re: [VOTE] KIP-519: Make SSL context/engine configuration extensible
+1 (non-binding) Thanks Renuka M On Tue, Mar 31, 2020 at 2:07 AM Rajini Sivaram wrote: > Hi Jun, Maulin, > > org.apache.kafka.common.security.ssl contains internal classes like > SslFactory. org.apache.kafka.common.security.auth is a public package > which contains all our current authentication-related classes. If we want > to move the new interface into an SSL-specific package, we should perhaps > create a new public package rather than use an existing internal one? > > On Tue, Mar 31, 2020 at 7:56 AM Manikumar > wrote: > > > +1 (binding). > > Thanks for the KIP. > > > > Thanks, > > Manikumar > > > > On Tue, Mar 31, 2020 at 11:24 AM Maulin Vasavada < > > maulin.vasav...@gmail.com> > > wrote: > > > > > Hi all, > > > > > > So far we got 3 Binding votes. I am planning to keep the voting phase > > open > > > until Tuesday 10 PM Pacific Time which will be more than 72 hours from > > the > > > first binding vote on Thursday 12:36 PM Pacific Time. > > > > > > Thanks > > > Maulin > > > > > > On Mon, Mar 30, 2020 at 10:32 PM Maulin Vasavada < > > > maulin.vasav...@gmail.com> > > > wrote: > > > > > > > Hi all, > > > > > > > > I updated the Javadoc in the KIP details and the actual > > SslEngineFactory > > > > interface for shouldBeRebuilt(). For the first comment, probably I'll > > try > > > > to address it tomorrow. > > > > > > > > Thanks > > > > Maulin > > > > > > > > On Mon, Mar 30, 2020 at 7:44 PM Maulin Vasavada < > > > maulin.vasav...@gmail.com> > > > > wrote: > > > > > > > >> Thanks Jun Rao for your vote and comments. > > > >> > > > >> For 1) Earlier it was the security.ssl package but after a review I > > > >> changed it to .auth since there are some public interfaces in that > > > package. > > > >> I am open to move it under .ssl package. > > > >> > > > >> For 2) Sure. Will document in Javadocs for the method. > > > >> > > > >> Thanks > > > >> Maulin > > > >> > > > >> On Mon, Mar 30, 2020 at 5:46 PM Jun Rao wrote: > > > >> > > > >>> Hi, Maulin, > > > >>> > > > >>> Thanks for the KIP. +1 from me. Just a couple of minor comments > > below. > > > >>> > > > >>> 1. Should the package name of the new > > > >>> interface SslEngineFactory be org.apache.kafka.common.security.ssl > > > >>> instead > > > >>> of org.apache.kafka.common.security.auth? > > > >>> 2. Could you document when shouldBeRebuilt() will be called? > > > >>> > > > >>> Jun > > > >>> > > > >>> On Mon, Mar 30, 2020 at 5:07 PM Maulin Vasavada < > > > >>> maulin.vasav...@gmail.com> > > > >>> wrote: > > > >>> > > > >>> > ^^^ bump ^^^ The vote is open for 2-3 days and gotten 1 Binding > > vote > > > >>> so > > > >>> > far, can you please vote so that we can try to move forward with > > > >>> changes? > > > >>> > > > > >>> > On Thu, Mar 26, 2020 at 4:11 PM Zhou, Thomas > > > > > >>> > > > > >>> > wrote: > > > >>> > > > > >>> > > +1 (non-binding) > > > >>> > > > > > >>> > > Regards, > > > >>> > > Thomas > > > >>> > > > > > >>> > > On 3/26/20, 12:36 PM, "Rajini Sivaram" < > rajinisiva...@gmail.com > > > > > > >>> wrote: > > > >>> > > > > > >>> > > +1 (binding) > > > >>> > > Thanks for the KIP, Maulin! > > > >>> > > > > > >>> > > Regards, > > > >>> > > > > > >>> > > Rajini > > > >>> > > > > > >>> > > On Thu, Mar 26, 2020 at 4:14 PM Maulin Vasavada < > > > >>> > > maulin.vasav...@gmail.com> > > > >>> > > wrote: > > > >>> > > > > > >>> > >
