Commercial support

[fpapon]

Hi,

I'm looking for a commercial support company page on the official 
website (https://kafka.apache.org) but I cannot find one.


Is such of page exist?

Regards,

Francois

Re: Commercial support

[Bruno Cadonna]

Hi Francois,

I am not aware of such a page on the Apache Kafka website.

There are a variety of companies that sell Kafka as a self-hosted 
platform or as a Cloud-hosted service.


Those companies include Confluent (disclaimer: I work for them), Red 
Hat, AWS, Aiven, Instaclustr, Cloudera, and more.



Best,
Bruno

On 28.09.22 10:38, fpapon wrote:

Hi,

I'm looking for a commercial support company page on the official 
website (https://kafka.apache.org) but I cannot find one.


Is such of page exist?

Regards,

Francois

[jira] [Resolved] (KAFKA-14257) Unexpected error INCONSISTENT_CLUSTER_ID in VOTE response

[jianbin.chen (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jianbin.chen resolved KAFKA-14257.
--
Resolution: Done

> Unexpected error INCONSISTENT_CLUSTER_ID in VOTE response
> -
>
> Key: KAFKA-14257
> URL: https://issues.apache.org/jira/browse/KAFKA-14257
> Project: Kafka
>  Issue Type: Bug
>  Components: kraft
>Affects Versions: 3.2.3
>Reporter: jianbin.chen
>Priority: Major
>
> Please help me see why the error message is output indefinitely
> broker1：
> {code:java}
> process.roles=broker,controller
> listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
> node.id=1
> listeners=PLAINTEXT://192.168.6.57:9092,CONTROLLER://192.168.6.57:9093
> inter.broker.listener.name=PLAINTEXT
> advertised.listeners=PLAINTEXT://192.168.6.57:9092
> controller.listener.names=CONTROLLER
> num.io.threads=8
> num.network.threads=5
> controller.quorum.voters=1@192.168.6.57:9093,2@192.168.6.56:9093,3@192.168.6.55:9093
> log.dirs=/data01/kafka323-logs{code}
> broker2
> {code:java}
> process.roles=broker,controller
> controller.listener.names=CONTROLLER
> num.io.threads=8
> num.network.threads=5
> listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
> node.id=2
> listeners=PLAINTEXT://192.168.6.56:9092,CONTROLLER://192.168.6.56:9093
> inter.broker.listener.name=PLAINTEXT
> controller.quorum.voters=1@192.168.6.57:9093,2@192.168.6.56:9093,3@192.168.6.55:9093
> log.dirs=/data01/kafka323-logs{code}
> broker3
> {code:java}
> process.roles=broker,controller
> controller.listener.names=CONTROLLER
> num.io.threads=8
> num.network.threads=5
> node.id=3
> listeners=PLAINTEXT://192.168.6.55:9092,CONTROLLER://192.168.6.55:9093
> inter.broker.listener.name=PLAINTEXT
> controller.quorum.voters=1@192.168.6.57:9093,2@192.168.6.56:9093,3@192.168.6.55:9093
> log.dirs=/data01/kafka323-logs
> {code}
> error msg：
> {code:java}
> [2022-09-22 18:44:01,601] ERROR [RaftManager nodeId=2] Unexpected error 
> INCONSISTENT_CLUSTER_ID in VOTE response: InboundResponse(correlationId=378, 
> data=VoteResponseData(errorCode=104, topics=[]), sourceId=1) 
> (org.apache.kafka.raft.KafkaRaftClient)
> [2022-09-22 18:44:01,625] ERROR [RaftManager nodeId=2] Unexpected error 
> INCONSISTENT_CLUSTER_ID in VOTE response: InboundResponse(correlationId=380, 
> data=VoteResponseData(errorCode=104, topics=[]), sourceId=1) 
> (org.apache.kafka.raft.KafkaRaftClient)
> [2022-09-22 18:44:01,655] ERROR [RaftManager nodeId=2] Unexpected error 
> INCONSISTENT_CLUSTER_ID in VOTE response: InboundResponse(correlationId=382, 
> data=VoteResponseData(errorCode=104, topics=[]), sourceId=1) 
> (org.apache.kafka.raft.KafkaRaftClient)
> [2022-09-22 18:44:01,679] ERROR [RaftManager nodeId=2] Unexpected error 
> INCONSISTENT_CLUSTER_ID in VOTE response: InboundResponse(correlationId=384, 
> data=VoteResponseData(errorCode=104, topics=[]), sourceId=1) 
> (org.apache.kafka.raft.KafkaRaftClient)
> [2022-09-22 18:44:01,706] ERROR [RaftManager nodeId=2] Unexpected error 
> INCONSISTENT_CLUSTER_ID in VOTE response: InboundResponse(correlationId=386, 
> data=VoteResponseData(errorCode=104, topics=[]), sourceId=1) 
> (org.apache.kafka.raft.KafkaRaftClient)
> [2022-09-22 18:44:01,729] ERROR [RaftManager nodeId=2] Unexpected error 
> INCONSISTENT_CLUSTER_ID in VOTE response: InboundResponse(correlationId=388, 
> data=VoteResponseData(errorCode=104, topics=[]), sourceId=1) 
> (org.apache.kafka.raft.KafkaRaftClient){code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] KIP-872: Add Serializer#serializeToByteBuffer() to reduce memory copying

[Divij Vaidya]

Hello

I believe that the current behaviour of creating a copy of the user
provided input is the correct approach because of the following reasons:

1. In the existing implementation (considering cases when T is ByteBuffer
in Serializer#serialize(String,Headers,T)) we copy the data (T) into a new
byte[]. In the new approach, we would continue to re-use the ByteBuffer
even after doSend() which means the `ProducerRecord` object cannot go out
of scope from a GC perspective at the end of doSend(). Hence, the new
approach may lead to increased heap memory usage for a greater period of
time.

2. The new approach may break certain user applications e.g. consider an
user application which re-uses the ByteBuffer (maybe it's a memory mapped
byte buffer) to send consecutive Producer.send() requests. Prior to this
change, they could do that because we copy the data from user provided
input before storing it in the accumulator but after this change, they will
have to allocate a new ByteBuffer for every ProduceRecord.

In general, I am of the opinion that any user provided data should be
copied to internal data structures at the interface of an opaque library
(like client) so that the user doesn't have to guess about memory lifetime
of the objects they provided to the opaque library.

What do you think?

--
Divij Vaidya



On Sun, Sep 25, 2022 at 5:59 PM ShunKang Lin 
wrote:

> Hi all, I'd like to start a new discussion thread on KIP-872 (Kafka Client)
> which proposes that add Serializer#serializeToByteBuffer() to reduce memory
> copying.
>
> KIP:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228495828
> Thanks, ShunKang
>

Re: [VOTE] 3.3.0 RC2

[Divij Vaidya]

Hey folks

I noticed a non-blocking bug with the documentation page where the arrow to
left nav overlaps with the text and a blue color vertical bar appears at
the right side. Please see the highlighted elements in the attached image.
In contrast, the current documentation page does not have this bug.

Reproducer:
1. Visit https://kafka.apache.org/33/documentation.html on a chrome browser.
2. Observe that arrow to expand left nav overlaps with text.
3. Remove "33/" from the url to observe the current documentation.
4. Observe that the current website does not have this bug.


Divij Vaidya



On Tue, Sep 27, 2022 at 8:35 PM David Arthur  wrote:

> I re-ran the failing system tests last night and got passing builds
> for each. There is still some flakiness it seems.
>
> Round trip test:
>
> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664223686--apache--3.3--9b8a48ca2a/2022-09-26--001./2022-09-26--001./report.html
>
> Upgrade test:
> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664235839--apache--3.3--1ce7bd7f29/2022-09-26--001./2022-09-26--001./report.html
>
> I was also able to verify that the failing delegation token test was
> not a regression, rather it was an issue with the test. I've opened a
> PR with a fix for the test https://github.com/apache/kafka/pull/12693.
> Included in the PR are the results of this fix applied to the 3.3
> branch (confirming we don't have a regression).
>
> I also filed a JIRA for the flaky upgrade_test
> https://issues.apache.org/jira/browse/KAFKA-14263
>
> With all that out of the way, I'm happy to close this vote with the
> following results:
>
> 5 binding +1 votes from PMC members John R, David J, Bill B, Ismael J,
> and Mickael M.
> 1 non-binding +1 community vote from Jakub Scholz
> No -1 votes
>
> The vote for Apache Kafka 3.3 passes!
>
> Thanks to everyone who voted and helped verify this release! A special
> thanks to José who has driven the release up to this point.
>
> Best,
> David Arthur
>
>
> On Tue, Sep 27, 2022 at 6:50 AM Mickael Maison 
> wrote:
> >
> > +1 (binding)
> > I checked the signatures/checksums, built from source and ran tests,
> > and ran the quickstart with the 2.13 binaries.
> >
> > Thanks José and David for running this release
> >
> > On Mon, Sep 26, 2022 at 11:07 PM David Arthur 
> wrote:
> > >
> > > Thanks for the votes, everyone!
> > >
> > > Here is the best recent run of the system tests on 3.3
> > >
> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/3.3/2022-09-24--001.system-test-kafka-3.3--1664037736--confluentinc--3.3--b084e9068c/report.html
> .
> > > I'm currently re-running the failed tests to confirm that they are
> > > merely flaky and not broken. One exception is the failing delegation
> > > token test that is consistently failing. This appears to be an issue
> > > with the test itself due to changes in the command output introduced
> > > recently.
> > >
> > > Similarly, the unit/integration tests are mostly passing, with some
> > > flaky failures. Here is a recent run that has two out of three jobs
> > > passing https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.3/86/.
> > >
> > > Once I verify the system tests are good, I'll update this thread and
> > > close out the vote.
> > >
> > > Thanks!
> > > David
> > >
> > >
> > > On Mon, Sep 26, 2022 at 2:24 PM Ismael Juma  wrote:
> > > >
> > > > +1 provided that the system test results are good. Can you please
> post them
> > > > along with the JUnit test results (these seem ok although there are
> some
> > > > flakes)?
> > > >
> > > > I tested the kraft quick start with the Scala 2.13 binary and ran
> the tests
> > > > on the source release. I noticed a non-blocker issue with the KRaft
> readme
> > > > and submitted a PR:
> > > >
> > > > https://github.com/apache/kafka/pull/12688
> > > >
> > > > Ismael
> > > >
> > > > On Tue, Sep 20, 2022 at 4:17 PM David Arthur 
> wrote:
> > > >
> > > > > Hello Kafka users, developers and client-developers,
> > > > >
> > > > > This is the second release candidate for Apache Kafka 3.3.0. Many
> new
> > > > > features and bug fixes are included in this major release of
> Kafka. A
> > > > > significant number of the issues in this release are related to
> KRaft,
> > > > > which will be considered "production ready" as part of this release
> > > > > (KIP-833)
> > > > >
> > > > > KRaft improvements:
> > > > > * KIP-778: Online KRaft to KRaft Upgrades
> > > > > * KIP-833: Mark KRaft as Production Ready
> > > > > * KIP-835: Monitor Quorum health (many new KRaft metrics)
> > > > > * KIP-836: Expose voter lag via kafka-metadata-quorum.sh
> > > > > * KIP-841: Fenced replicas should not be allowed to join the ISR
> in KRaft
> > > > > * KIP-859: Add Metadata Log Processing Error Related Metrics
> > > > >
> > > > > Other major improvements include:
> > > > > * KIP-618: Exactly-Once Support f

Re: [VOTE] 3.3.0 RC2

[Divij Vaidya]

Please ignore my previous email. Seems like that is a known issue and we
plan to fix it after the release.

Divij Vaidya



On Wed, Sep 28, 2022 at 3:08 PM Divij Vaidya 
wrote:

> Hey folks
>
> I noticed a non-blocking bug with the documentation page where the arrow
> to left nav overlaps with the text and a blue color vertical bar appears at
> the right side. Please see the highlighted elements in the attached image.
> In contrast, the current documentation page does not have this bug.
>
> Reproducer:
> 1. Visit https://kafka.apache.org/33/documentation.html on a
> chrome browser.
> 2. Observe that arrow to expand left nav overlaps with text.
> 3. Remove "33/" from the url to observe the current documentation.
> 4. Observe that the current website does not have this bug.
>
>
> Divij Vaidya
>
>
>
> On Tue, Sep 27, 2022 at 8:35 PM David Arthur 
> wrote:
>
>> I re-ran the failing system tests last night and got passing builds
>> for each. There is still some flakiness it seems.
>>
>> Round trip test:
>>
>> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664223686--apache--3.3--9b8a48ca2a/2022-09-26--001./2022-09-26--001./report.html
>>
>> Upgrade test:
>> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664235839--apache--3.3--1ce7bd7f29/2022-09-26--001./2022-09-26--001./report.html
>>
>> I was also able to verify that the failing delegation token test was
>> not a regression, rather it was an issue with the test. I've opened a
>> PR with a fix for the test https://github.com/apache/kafka/pull/12693.
>> Included in the PR are the results of this fix applied to the 3.3
>> branch (confirming we don't have a regression).
>>
>> I also filed a JIRA for the flaky upgrade_test
>> https://issues.apache.org/jira/browse/KAFKA-14263
>>
>> With all that out of the way, I'm happy to close this vote with the
>> following results:
>>
>> 5 binding +1 votes from PMC members John R, David J, Bill B, Ismael J,
>> and Mickael M.
>> 1 non-binding +1 community vote from Jakub Scholz
>> No -1 votes
>>
>> The vote for Apache Kafka 3.3 passes!
>>
>> Thanks to everyone who voted and helped verify this release! A special
>> thanks to José who has driven the release up to this point.
>>
>> Best,
>> David Arthur
>>
>>
>> On Tue, Sep 27, 2022 at 6:50 AM Mickael Maison 
>> wrote:
>> >
>> > +1 (binding)
>> > I checked the signatures/checksums, built from source and ran tests,
>> > and ran the quickstart with the 2.13 binaries.
>> >
>> > Thanks José and David for running this release
>> >
>> > On Mon, Sep 26, 2022 at 11:07 PM David Arthur 
>> wrote:
>> > >
>> > > Thanks for the votes, everyone!
>> > >
>> > > Here is the best recent run of the system tests on 3.3
>> > >
>> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/3.3/2022-09-24--001.system-test-kafka-3.3--1664037736--confluentinc--3.3--b084e9068c/report.html
>> .
>> > > I'm currently re-running the failed tests to confirm that they are
>> > > merely flaky and not broken. One exception is the failing delegation
>> > > token test that is consistently failing. This appears to be an issue
>> > > with the test itself due to changes in the command output introduced
>> > > recently.
>> > >
>> > > Similarly, the unit/integration tests are mostly passing, with some
>> > > flaky failures. Here is a recent run that has two out of three jobs
>> > > passing https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.3/86/.
>> > >
>> > > Once I verify the system tests are good, I'll update this thread and
>> > > close out the vote.
>> > >
>> > > Thanks!
>> > > David
>> > >
>> > >
>> > > On Mon, Sep 26, 2022 at 2:24 PM Ismael Juma 
>> wrote:
>> > > >
>> > > > +1 provided that the system test results are good. Can you please
>> post them
>> > > > along with the JUnit test results (these seem ok although there are
>> some
>> > > > flakes)?
>> > > >
>> > > > I tested the kraft quick start with the Scala 2.13 binary and ran
>> the tests
>> > > > on the source release. I noticed a non-blocker issue with the KRaft
>> readme
>> > > > and submitted a PR:
>> > > >
>> > > > https://github.com/apache/kafka/pull/12688
>> > > >
>> > > > Ismael
>> > > >
>> > > > On Tue, Sep 20, 2022 at 4:17 PM David Arthur <
>> davidart...@apache.org> wrote:
>> > > >
>> > > > > Hello Kafka users, developers and client-developers,
>> > > > >
>> > > > > This is the second release candidate for Apache Kafka 3.3.0. Many
>> new
>> > > > > features and bug fixes are included in this major release of
>> Kafka. A
>> > > > > significant number of the issues in this release are related to
>> KRaft,
>> > > > > which will be considered "production ready" as part of this
>> release
>> > > > > (KIP-833)
>> > > > >
>> > > > > KRaft improvements:
>> > > > > * KIP-778: Online KRaft to KRaft Upgrades
>> > > > > * KIP-833: Mark KRaft as Production Ready
>> > > > > * KIP-835: Monitor Quorum h

Re: [DISCUSS] KIP-852 Optimize calculation of size for log in remote tier

[Divij Vaidya]

Hey folks

Does anyone else have any thoughts on this before I propose this for a
vote?

--
Divij Vaidya



On Mon, Sep 5, 2022 at 12:57 PM Satish Duggana 
wrote:

> Thanks for the KIP Divij!
>
> This is a nice improvement to avoid recalculation of size. Customized RLMMs
> can implement the best possible approach by caching or maintaining the size
> in an efficient way. But this is not a big concern for the default topic
> based RLMM as mentioned in the KIP.
>
> ~Satish.
>
> On Wed, 13 Jul 2022 at 18:48, Divij Vaidya 
> wrote:
>
> > Thank you for your review Luke.
> >
> > > Reg: is that would the new `RemoteLogSizeBytes` metric be a performance
> > overhead? Although we move the calculation to a seperate API, we still
> > can't assume users will implement a light-weight method, right?
> >
> > This metric would be logged using the information that is already being
> > calculated for handling remote retention logic, hence, no additional work
> > is required to calculate this metric. More specifically, whenever
> > RemoteLogManager calls getRemoteLogSize API, this metric would be
> captured.
> > This API call is made every time RemoteLogManager wants to handle expired
> > remote log segments (which should be periodic). Does that address your
> > concern?
> >
> > Divij Vaidya
> >
> >
> >
> > On Tue, Jul 12, 2022 at 11:01 AM Luke Chen  wrote:
> >
> > > Hi Divij,
> > >
> > > Thanks for the KIP!
> > >
> > > I think it makes sense to delegate the responsibility of calculation to
> > the
> > > specific RemoteLogMetadataManager implementation.
> > > But one thing I'm not quite sure, is that would the new
> > > `RemoteLogSizeBytes` metric be a performance overhead?
> > > Although we move the calculation to a seperate API, we still can't
> assume
> > > users will implement a light-weight method, right?
> > >
> > > Thank you.
> > > Luke
> > >
> > > On Fri, Jul 1, 2022 at 5:47 PM Divij Vaidya 
> > > wrote:
> > >
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-852%3A+Optimize+calculation+of+size+for+log+in+remote+tier
> > > >
> > > >
> > > > Hey folks
> > > >
> > > > Please take a look at this KIP which proposes an extension to
> KIP-405.
> > > This
> > > > is my first KIP with Apache Kafka community so any feedback would be
> > > highly
> > > > appreciated.
> > > >
> > > > Cheers!
> > > >
> > > > --
> > > > Divij Vaidya
> > > > Sr. Software Engineer
> > > > Amazon
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-868 Metadata Transactions (new thread)

[David Arthur]

Thanks Luke, I failed to mention in my reply to Ziming, but I did add this
sentence to the end of the "visibility" section:

The metadata shell must also avoid showing partially committed metadata
> transactions.



-David

On Tue, Sep 27, 2022 at 10:20 PM Luke Chen  wrote:

> Hi David,
>
> I think there's still an unanswered question from Ziming:
> > I think we can also describe visibility in the MetadataShell since it is
> also a public interface.
>
> I think this suggestion makes sense.
> But I'm still +1 for current proposal.
>
> Thanks.
> Luke
>
> On Tue, Sep 27, 2022 at 11:11 PM David Arthur 
> wrote:
>
> > Thanks for the reviews, everyone. I’ve started a VOTE thread
> >
> > -David
> >
> > On Fri, Sep 23, 2022 at 00:55 deng ziming 
> > wrote:
> >
> > > David,
> > > Thanks for the feedback about #2 and #3, I'm OK with them.
> > > I also mentioned the visibility in the MetadataShell in #1, do you have
> > any
> > > thoughts?
> > >
> > > --
> > > Best,
> > > Ziming
> > >
> > > On Wed, Sep 21, 2022 at 10:56 PM David Arthur 
> wrote:
> > >
> > > > Ziming, thanks for the feedback! Let me know your thoughts on #2 and
> #3
> > > >
> > > > 1. Good idea. I consolidated all the details of record visibility
> into
> > > > that section.
> > > >
> > > > 2. I'm not sure we can always know the number of records ahead of
> time
> > > > for a transaction. One future use case is likely for the ZK data
> > > > migration which will have an undetermined number of records. I would
> > > > be okay with some short textual fields like "name" for the Begin
> > > > record and "reason" for the Abort record. These could also be tagged
> > > > fields if we don't want to always include them in the records.
> > > >
> > > > 3. The metadata records end up in org.apache.kafka.common.metadata,
> so
> > > > maybe we can avoid Metadata in the name since it's kind of implicit.
> > > > I'd be okay with [Begin|End|Abort]TransactionRecord.
> > > >
> > > > -David
> > > >
> > > > On Mon, Sep 19, 2022 at 10:58 PM deng ziming <
> dengziming1...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > Hello David,
> > > > > Thanks for the KIP, certainly it makes sense, I left some minor
> > > > questions.
> > > > >
> > > > > 1. In “Record Visibility” section you declare visibility in the
> > > > controller, in “Broker Support” you mention visibility in the broker,
> > we
> > > > can put them together, and I think we can also describe visibility in
> > the
> > > > MetadataShell since it is also a public interface.
> > > > >
> > > > > 2. In “Public interfaces” section, I found that the
> > “BeginMarkerRecord”
> > > > has no fields, should we include some auxiliary attributes to help
> > parse
> > > > the transaction, for example, number of records in this transaction.
> > > > >
> > > > > 3. The record name seems vague, and we already have a
> > > > `EndTransactionMarker` class in `org.apache.kafka.common.record`, how
> > > about
> > > > `BeginMetadataTransactionRecord`?
> > > > >
> > > > > - -
> > > > > Best,
> > > > > Ziming
> > > > >
> > > > > > On Sep 10, 2022, at 1:13 AM, David Arthur <
> davidart...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > Starting a new thread to avoid issues with mail client threading.
> > > > > >
> > > > > > Original thread follows:
> > > > > >
> > > > > > Hey folks, I'd like to start a discussion on the idea of adding
> > > > > > transactions in the KRaft controller. This will allow us to
> > overcome
> > > > > > the current limitation of atomic batch sizes in Raft which lets
> us
> > do
> > > > > > things like create topics with a huge number of partitions.
> > > > > >
> > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-868+Metadata+Transactions
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Colin McCabe said:
> > > > > >
> > > > > > Thanks for this KIP, David!
> > > > > >
> > > > > > In the "motivation" section, it might help to give a concrete
> > example
> > > > > > of an operation we want to be atomic. My favorite one is probably
> > > > > > CreateTopics since it's easy to see that we want to create all
> of a
> > > > > > topic or none of it, and a topic could be a potentially unbounded
> > > > > > number of records (although hopefully people have reasonable
> create
> > > > > > topic policy classes in place...)
> > > > > >
> > > > > > In "broker support", it would be good to clarify that we will
> > buffer
> > > > > > the records in the MetadataDelta and not publish a new
> > MetadataImage
> > > > > > until the transaction is over. This is an implementation detail,
> > but
> > > > > > it's a simple one and I think it will make it easier to
> understand
> > > how
> > > > > > this works.
> > > > > >
> > > > > > In the "Raft Transactions" section of "Rejected Alternatives,"
> I'd
> > > add
> > > > > > that managing buffering in the Raft layer would be a lot less
> > > > > > efficient than doing it in the controller / broker layer. We
> would
> > >

Re: [VOTE] 3.3.0 RC2

[David Arthur]

Thanks Divij, we made a bunch of documentation changes at the last minute
for this release, so we’re trying to figure out when the issue was
introduced. I’m hoping we can fix it before we send out the announcement.

Thanks for calling it out :)

Best,
David

On Wed, Sep 28, 2022 at 09:11 Divij Vaidya  wrote:

> Please ignore my previous email. Seems like that is a known issue and we a
> plan to fix it after the release.
>
> Divij Vaidya
>
>
>
> On Wed, Sep 28, 2022 at 3:08 PM Divij Vaidya 
> wrote:
>
> > Hey folks
> >
> > I noticed a non-blocking bug with the documentation page where the arrow
> > to left nav overlaps with the text and a blue color vertical bar appears
> at
> > the right side. Please see the highlighted elements in the attached
> image.
> > In contrast, the current documentation page does not have this bug.
> >
> > Reproducer:
> > 1. Visit https://kafka.apache.org/33/documentation.html on a
> > chrome browser.
> > 2. Observe that arrow to expand left nav overlaps with text.
> > 3. Remove "33/" from the url to observe the current documentation.
> > 4. Observe that the current website does not have this bug.
> >
> >
> > Divij Vaidya
> >
> >
> >
> > On Tue, Sep 27, 2022 at 8:35 PM David Arthur 
> > wrote:
> >
> >> I re-ran the failing system tests last night and got passing builds
> >> for each. There is still some flakiness it seems.
> >>
> >> Round trip test:
> >>
> >>
> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664223686--apache--3.3--9b8a48ca2a/2022-09-26--001./2022-09-26--001./report.html
> >>
> >> Upgrade test:
> >>
> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664235839--apache--3.3--1ce7bd7f29/2022-09-26--001./2022-09-26--001./report.html
> >>
> >> I was also able to verify that the failing delegation token test was
> >> not a regression, rather it was an issue with the test. I've opened a
> >> PR with a fix for the test https://github.com/apache/kafka/pull/12693.
> >> Included in the PR are the results of this fix applied to the 3.3
> >> branch (confirming we don't have a regression).
> >>
> >> I also filed a JIRA for the flaky upgrade_test
> >> https://issues.apache.org/jira/browse/KAFKA-14263
> >>
> >> With all that out of the way, I'm happy to close this vote with the
> >> following results:
> >>
> >> 5 binding +1 votes from PMC members John R, David J, Bill B, Ismael J,
> >> and Mickael M.
> >> 1 non-binding +1 community vote from Jakub Scholz
> >> No -1 votes
> >>
> >> The vote for Apache Kafka 3.3 passes!
> >>
> >> Thanks to everyone who voted and helped verify this release! A special
> >> thanks to José who has driven the release up to this point.
> >>
> >> Best,
> >> David Arthur
> >>
> >>
> >> On Tue, Sep 27, 2022 at 6:50 AM Mickael Maison <
> mickael.mai...@gmail.com>
> >> wrote:
> >> >
> >> > +1 (binding)
> >> > I checked the signatures/checksums, built from source and ran tests,
> >> > and ran the quickstart with the 2.13 binaries.
> >> >
> >> > Thanks José and David for running this release
> >> >
> >> > On Mon, Sep 26, 2022 at 11:07 PM David Arthur  >
> >> wrote:
> >> > >
> >> > > Thanks for the votes, everyone!
> >> > >
> >> > > Here is the best recent run of the system tests on 3.3
> >> > >
> >>
> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/3.3/2022-09-24--001.system-test-kafka-3.3--1664037736--confluentinc--3.3--b084e9068c/report.html
> >> .
> >> > > I'm currently re-running the failed tests to confirm that they are
> >> > > merely flaky and not broken. One exception is the failing delegation
> >> > > token test that is consistently failing. This appears to be an issue
> >> > > with the test itself due to changes in the command output introduced
> >> > > recently.
> >> > >
> >> > > Similarly, the unit/integration tests are mostly passing, with some
> >> > > flaky failures. Here is a recent run that has two out of three jobs
> >> > > passing
> https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.3/86/.
> >> > >
> >> > > Once I verify the system tests are good, I'll update this thread and
> >> > > close out the vote.
> >> > >
> >> > > Thanks!
> >> > > David
> >> > >
> >> > >
> >> > > On Mon, Sep 26, 2022 at 2:24 PM Ismael Juma 
> >> wrote:
> >> > > >
> >> > > > +1 provided that the system test results are good. Can you please
> >> post them
> >> > > > along with the JUnit test results (these seem ok although there
> are
> >> some
> >> > > > flakes)?
> >> > > >
> >> > > > I tested the kraft quick start with the Scala 2.13 binary and ran
> >> the tests
> >> > > > on the source release. I noticed a non-blocker issue with the
> KRaft
> >> readme
> >> > > > and submitted a PR:
> >> > > >
> >> > > > https://github.com/apache/kafka/pull/12688
> >> > > >
> >> > > > Ismael
> >> > > >
> >> > > > On Tue, Sep 20, 2022 at 4:17 PM David Arthur <
> >> davidart...@apache.org> wrote:
> >> > > >
> >> > > > >

Re: [DISCUSS] KIP-870: Retention policy based on record event time

[Николай Ижиков]

Hello! 

Please, share your feedback?
Is proposed retention policy can be useful for Kafka users?

> 21 сент. 2022 г., в 13:02, Николай Ижиков  написал(а):
> 
> Hello.
> 
> I want to start discussion of KIP-870 [1] [2].
> 
> The goal of this KIP is to provide new retention policy purely based on 
> record event time.
> 
> [1] 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-870%3A+Retention+policy+based+on+record+event+time
> [2] https://issues.apache.org/jira/browse/KAFKA-13866
> 

Re: [DISCUSS] KIP-870: Retention policy based on record event time

[Divij Vaidya]

Hello

Thank you for the KIP.

Could you please add the following items to the KIP to make it easier to
review.

1. Please add some more details on "Especially for Kafka Stream, we have
seen many cases when users got bit by the current behavior.". What were the
scenarios that impacted users of Kafka and what was the impact? This would
help us understand the motivation for this change.
2. What are the side effects of this approach and why are they an
acceptable trade-off? e.g. the solution increases the record size on the
disk etc.
3. What is the reason for which we rejected the alternative of increasing
the retention time? (probably covered by answer to 1 above)
4. How is max event time calculated on broker startup? Is it persisted
somewhere or is it kept in-memory and updated with every record?
5. How do we guarantee "keep at max" since data eviction is asynchronous in
nature and may not provide "at max" guarantee. It can provide "at least"
guarantee.

--
Divij Vaidya



On Wed, Sep 28, 2022 at 3:47 PM Николай Ижиков  wrote:

> Hello!
>
> Please, share your feedback?
> Is proposed retention policy can be useful for Kafka users?
>
> > 21 сент. 2022 г., в 13:02, Николай Ижиков 
> написал(а):
> >
> > Hello.
> >
> > I want to start discussion of KIP-870 [1] [2].
> >
> > The goal of this KIP is to provide new retention policy purely based on
> record event time.
> >
> > [1]
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-870%3A+Retention+policy+based+on+record+event+time
> > [2] https://issues.apache.org/jira/browse/KAFKA-13866
> >
>
>

Re: [VOTE] KIP-868 Metadata Transactions

[David Jacot]

+1 (binding). Thanks for the KIP. I really like the approach!

Best,
David

On Wed, Sep 28, 2022 at 4:20 AM Luke Chen  wrote:
>
> Hi David,
>
> +1 (binding) from me.
>
> Thank you
> Luke
>
> On Tue, Sep 27, 2022 at 11:02 PM David Arthur 
> wrote:
>
> > Hey folks, I'd like to start a vote on KIP-868. This proposal adds
> > lightweight transactions to the KRaft controller. These transactions
> > will allow us to generate atomic batches of records that exceed the
> > current limits of the metadata layer.
> >
> > Here is the KIP:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-868+Metadata+Transactions
> >
> > And previous discussion:
> > https://lists.apache.org/thread/895pgb85l08g2l63k99cw5dt2qpjkxb9
> >
> > Thanks to all who have reviewed so far!
> >
> > Cheers,
> > David
> >

Re: [DISCUSS] KIP-872: Add Serializer#serializeToByteBuffer() to reduce memory copying

[ShunKang Lin]

Hi Divij Vaidya,

Thanks for your comments.

1. I checked the code of KafkaProducer#doSend()
and RecordAccumulator#append(), if KafkaProducer#doSend() returns it means
serializedKey and serializedValue have been appended to
ProducerBatch#recordsBuilder and we don't keep reference of serializedKey
and serializedValue.

2. According to 1, the user application can reuse the ByteBuffer to send
consecutive KafkaProducer#send() requests without breaking the user
application. If we are concerned about compatibility, we can provide
another Serializer, such as ZeroCopyByteBufferSerializer, and keep the
original ByteBufferSerializer unchanged.

In my opinion, kafka-clients should provide some way for users who want to
improve application performance, if users want to improve application
performance, they should use lower level code and understand the underlying
implementation of these codes.

Best,
ShunKang

Divij Vaidya  于2022年9月28日周三 19:58写道：

> Hello
>
> I believe that the current behaviour of creating a copy of the user
> provided input is the correct approach because of the following reasons:
>
> 1. In the existing implementation (considering cases when T is ByteBuffer
> in Serializer#serialize(String,Headers,T)) we copy the data (T) into a new
> byte[]. In the new approach, we would continue to re-use the ByteBuffer
> even after doSend() which means the `ProducerRecord` object cannot go out
> of scope from a GC perspective at the end of doSend(). Hence, the new
> approach may lead to increased heap memory usage for a greater period of
> time.
>
> 2. The new approach may break certain user applications e.g. consider an
> user application which re-uses the ByteBuffer (maybe it's a memory mapped
> byte buffer) to send consecutive Producer.send() requests. Prior to this
> change, they could do that because we copy the data from user provided
> input before storing it in the accumulator but after this change, they will
> have to allocate a new ByteBuffer for every ProduceRecord.
>
> In general, I am of the opinion that any user provided data should be
> copied to internal data structures at the interface of an opaque library
> (like client) so that the user doesn't have to guess about memory lifetime
> of the objects they provided to the opaque library.
>
> What do you think?
>
> --
> Divij Vaidya
>
>
>
> On Sun, Sep 25, 2022 at 5:59 PM ShunKang Lin 
> wrote:
>
> > Hi all, I'd like to start a new discussion thread on KIP-872 (Kafka
> Client)
> > which proposes that add Serializer#serializeToByteBuffer() to reduce
> memory
> > copying.
> >
> > KIP:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228495828
> > Thanks, ShunKang
> >
>

[GitHub] [kafka-site] mumrah opened a new pull request, #446: MINOR: quick fix for TOC handle

[GitBox]

mumrah opened a new pull request, #446:
URL: https://github.com/apache/kafka-site/pull/446

   Seen in the prerelease of the 3.3 docs, the TOC handle overlaps with the 
main contents of the `.right` div.
   
   The left margin for this div was "auto", which was not getting calculated 
correctly. This patch sets the left margin to 33 rem which is what the actual 
left margin is supposed to be. Since the TOC and handle are fixed width, it's 
okay to use a fixed margin as well.
   
   
   
   **Current 3.3 docs:**
   
   
   https://user-images.githubusercontent.com/55116/192832666-3534e0aa-b242-4ffa-97e1-e49a16b61164.png";>
   
   
   
   **With this patch:**
   
   
   https://user-images.githubusercontent.com/55116/192832744-006838ea-04f6-480c-a7b7-c8964b9f7473.png";>
   
   
   
   There is likely some other issue in the body elements causing this margin to 
get miscalculated, though I couldn't find the root cause. 
   
   Tested in Chrome 106.0.5249.61 and Safari 15.6.1 on Mac OS 12.5.1.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Jenkins build is unstable: Kafka » Kafka Branch Builder » 3.3 #91

[Apache Jenkins Server]

See 

Re: [VOTE] 3.3.0 RC2

[David Arthur]

For those interested, here's a PR to fix the HTML rendering issue:
https://github.com/apache/kafka-site/pull/446

-David

On Wed, Sep 28, 2022 at 9:45 AM David Arthur  wrote:
>
> Thanks Divij, we made a bunch of documentation changes at the last minute for 
> this release, so we’re trying to figure out when the issue was introduced. 
> I’m hoping we can fix it before we send out the announcement.
>
> Thanks for calling it out :)
>
> Best,
> David
>
> On Wed, Sep 28, 2022 at 09:11 Divij Vaidya  wrote:
>>
>> Please ignore my previous email. Seems like that is a known issue and we a
>> plan to fix it after the release.
>>
>> Divij Vaidya
>>
>>
>>
>> On Wed, Sep 28, 2022 at 3:08 PM Divij Vaidya 
>> wrote:
>>
>> > Hey folks
>> >
>> > I noticed a non-blocking bug with the documentation page where the arrow
>> > to left nav overlaps with the text and a blue color vertical bar appears at
>> > the right side. Please see the highlighted elements in the attached image.
>> > In contrast, the current documentation page does not have this bug.
>> >
>> > Reproducer:
>> > 1. Visit https://kafka.apache.org/33/documentation.html on a
>> > chrome browser.
>> > 2. Observe that arrow to expand left nav overlaps with text.
>> > 3. Remove "33/" from the url to observe the current documentation.
>> > 4. Observe that the current website does not have this bug.
>> >
>> >
>> > Divij Vaidya
>> >
>> >
>> >
>> > On Tue, Sep 27, 2022 at 8:35 PM David Arthur 
>> > wrote:
>> >
>> >> I re-ran the failing system tests last night and got passing builds
>> >> for each. There is still some flakiness it seems.
>> >>
>> >> Round trip test:
>> >>
>> >> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664223686--apache--3.3--9b8a48ca2a/2022-09-26--001./2022-09-26--001./report.html
>> >>
>> >> Upgrade test:
>> >> http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1664235839--apache--3.3--1ce7bd7f29/2022-09-26--001./2022-09-26--001./report.html
>> >>
>> >> I was also able to verify that the failing delegation token test was
>> >> not a regression, rather it was an issue with the test. I've opened a
>> >> PR with a fix for the test https://github.com/apache/kafka/pull/12693.
>> >> Included in the PR are the results of this fix applied to the 3.3
>> >> branch (confirming we don't have a regression).
>> >>
>> >> I also filed a JIRA for the flaky upgrade_test
>> >> https://issues.apache.org/jira/browse/KAFKA-14263
>> >>
>> >> With all that out of the way, I'm happy to close this vote with the
>> >> following results:
>> >>
>> >> 5 binding +1 votes from PMC members John R, David J, Bill B, Ismael J,
>> >> and Mickael M.
>> >> 1 non-binding +1 community vote from Jakub Scholz
>> >> No -1 votes
>> >>
>> >> The vote for Apache Kafka 3.3 passes!
>> >>
>> >> Thanks to everyone who voted and helped verify this release! A special
>> >> thanks to José who has driven the release up to this point.
>> >>
>> >> Best,
>> >> David Arthur
>> >>
>> >>
>> >> On Tue, Sep 27, 2022 at 6:50 AM Mickael Maison 
>> >> wrote:
>> >> >
>> >> > +1 (binding)
>> >> > I checked the signatures/checksums, built from source and ran tests,
>> >> > and ran the quickstart with the 2.13 binaries.
>> >> >
>> >> > Thanks José and David for running this release
>> >> >
>> >> > On Mon, Sep 26, 2022 at 11:07 PM David Arthur 
>> >> wrote:
>> >> > >
>> >> > > Thanks for the votes, everyone!
>> >> > >
>> >> > > Here is the best recent run of the system tests on 3.3
>> >> > >
>> >> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/3.3/2022-09-24--001.system-test-kafka-3.3--1664037736--confluentinc--3.3--b084e9068c/report.html
>> >> .
>> >> > > I'm currently re-running the failed tests to confirm that they are
>> >> > > merely flaky and not broken. One exception is the failing delegation
>> >> > > token test that is consistently failing. This appears to be an issue
>> >> > > with the test itself due to changes in the command output introduced
>> >> > > recently.
>> >> > >
>> >> > > Similarly, the unit/integration tests are mostly passing, with some
>> >> > > flaky failures. Here is a recent run that has two out of three jobs
>> >> > > passing https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.3/86/.
>> >> > >
>> >> > > Once I verify the system tests are good, I'll update this thread and
>> >> > > close out the vote.
>> >> > >
>> >> > > Thanks!
>> >> > > David
>> >> > >
>> >> > >
>> >> > > On Mon, Sep 26, 2022 at 2:24 PM Ismael Juma 
>> >> wrote:
>> >> > > >
>> >> > > > +1 provided that the system test results are good. Can you please
>> >> post them
>> >> > > > along with the JUnit test results (these seem ok although there are
>> >> some
>> >> > > > flakes)?
>> >> > > >
>> >> > > > I tested the kraft quick start with the Scala 2.13 binary and ran
>> >> the tests
>> >> > > > on the source release. I noticed a non-blocker issue with the KRaft

[jira] [Resolved] (KAFKA-14259) BrokerRegistration#toString throws an exception, terminating metadata replay

[Jose Armando Garcia Sancio (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jose Armando Garcia Sancio resolved KAFKA-14259.

Resolution: Fixed

> BrokerRegistration#toString throws an exception, terminating metadata replay
> 
>
> Key: KAFKA-14259
> URL: https://issues.apache.org/jira/browse/KAFKA-14259
> Project: Kafka
>  Issue Type: Bug
>Reporter: Colin McCabe
>Assignee: Colin McCabe
>Priority: Blocker
> Fix For: 3.3.0
>
>
> BrokerRegistration#toString throws an exception, terminating metadata replay, 
> because the sorted() method is used on an entry set rather than a key set.
> {noformat}
> Caused by:
>   
>  
> java.util.concurrent.ExecutionException: 
> java.lang.ClassCastException: class java.util.HashMap$Node cannot be cast to 
> class java.lang.Comparable (java.util.HashMap$Node and java.lan
> g.Comparable are in module java.base of loader 'bootstrap')   
>   
>  
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396)
>   
>   
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
>   
>
> at kafka.server.BrokerServer.startup(BrokerServer.scala:846)  
>   
>  
> ... 147 more  
>   
>  
>   
>   
>  
> Caused by:
>   
>  
> java.lang.ClassCastException: class java.util.HashMap$Node cannot 
> be cast to class java.lang.Comparable (java.util.HashMap$Node and 
> java.lang.Comparable are in module java.base 
> of loader 'bootstrap')
>   
>  
> at 
> java.base/java.util.Comparators$NaturalOrderComparator.compare(Comparators.java:47)
>   
>  
> at 
> java.base/java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
>   
>   
> at java.base/java.util.TimSort.sort(TimSort.java:220) 
>   
>  
> at java.base/java.util.Arrays.sort(Arrays.java:1307)  
>   
>  
> at 
> java.base/java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:353)
>   
> 
> at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510)
>   
>  
> at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
>   
>   
> at 
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
>   
> 
> at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>   
>  
> at 
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
>

[GitHub] [kafka-site] bbejeck commented on pull request #446: MINOR: quick fix for TOC handle

[GitBox]

bbejeck commented on PR #446:
URL: https://github.com/apache/kafka-site/pull/446#issuecomment-1261467208

   ![Screen Shot 2022-09-28 at 5 04 04 
PM](https://user-images.githubusercontent.com/199238/192889051-a0599d26-5de3-4fe8-a671-3686598a799f.png)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] niket-goel commented on a diff in pull request #447: Update and publish docs for 3.3

[GitBox]

niket-goel commented on code in PR #447:
URL: https://github.com/apache/kafka-site/pull/447#discussion_r982881218


##
33/ops.html:
##
@@ -3401,6 +3401,121 @@ https://github.com/apache/kafka/pull/12679
   Have those been pushed to the site already?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mumrah commented on pull request #446: MINOR: quick fix for TOC handle

[GitBox]

mumrah commented on PR #446:
URL: https://github.com/apache/kafka-site/pull/446#issuecomment-1261503708

   Somehow I completely missed that bar thing. I think that's the culprit here, 
let me see if I can track down where its coming from


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mumrah commented on a diff in pull request #447: Update and publish docs for 3.3

[GitBox]

mumrah commented on code in PR #447:
URL: https://github.com/apache/kafka-site/pull/447#discussion_r982898151


##
33/ops.html:
##
@@ -3401,6 +3401,121 @@ 

[GitHub] [kafka-site] bbejeck commented on pull request #446: MINOR: quick fix for TOC handle

[GitBox]

bbejeck commented on PR #446:
URL: https://github.com/apache/kafka-site/pull/446#issuecomment-1261514052

   @mumrah the latest commit fixes it - thanks for the update


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mumrah merged pull request #446: MINOR: quick fix for TOC handle

[GitBox]

mumrah merged PR #446:
URL: https://github.com/apache/kafka-site/pull/446


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] bbejeck commented on pull request #447: Update and publish docs for 3.3

[GitBox]

bbejeck commented on PR #447:
URL: https://github.com/apache/kafka-site/pull/447#issuecomment-1261523307

   @mumrah thanks for the update - I clicked around on a bunch of links and 
from what I can see the docs point to the correct ones, including the 
quickstart  which points to 3.3 now


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] niket-goel commented on a diff in pull request #447: Update and publish docs for 3.3

[GitBox]

niket-goel commented on code in PR #447:
URL: https://github.com/apache/kafka-site/pull/447#discussion_r982914620


##
33/ops.html:
##
@@ -3401,6 +3401,121 @@ https://github.com/apache/kafka/commit/2e952805431f9d4a7deef5c7f8453c63aa9702db



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mumrah merged pull request #447: Update and publish docs for 3.3

[GitBox]

mumrah merged PR #447:
URL: https://github.com/apache/kafka-site/pull/447


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mumrah merged pull request #448: MINOR fix errant code elements

[GitBox]

mumrah merged PR #448:
URL: https://github.com/apache/kafka-site/pull/448


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mumrah merged pull request #449: MINOR Fix another missing code tag

[GitBox]

mumrah merged PR #449:
URL: https://github.com/apache/kafka-site/pull/449


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (KAFKA-14265) Prefix ACLs may shadow other prefix ACLs

[Colin McCabe (Jira)]

Colin McCabe created KAFKA-14265:


 Summary: Prefix ACLs may shadow other prefix ACLs
 Key: KAFKA-14265
 URL: https://issues.apache.org/jira/browse/KAFKA-14265
 Project: Kafka
  Issue Type: Bug
Reporter: Colin McCabe
Assignee: Colin McCabe


Prefix ACLs may shadow other prefix ACLs. Consider the case where we have 
prefix ACLs for foobar, fooa, and f. If we were matching a resource named 
"foobar", we'd start scanning at the foobar ACL, hit the fooa ACL, and stop -- 
missing the f ACL.

To fix this, we should re-scan for ACLs at the first divergence point (in this 
case, f) whenever we hit a mismatch of this kind.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [kafka-site] mumrah merged pull request #450: MINOR Fix download links

[GitBox]

mumrah merged PR #450:
URL: https://github.com/apache/kafka-site/pull/450


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [VOTE] KIP-868 Metadata Transactions

[deng ziming]

Thanks for this KIP,

+1(non-binding) from me.

--
Best,
Ziming

> On Sep 28, 2022, at 10:05 PM, David Jacot  wrote:
> 
> +1 (binding). Thanks for the KIP. I really like the approach!
> 
> Best,
> David
> 
> On Wed, Sep 28, 2022 at 4:20 AM Luke Chen  wrote:
>> 
>> Hi David,
>> 
>> +1 (binding) from me.
>> 
>> Thank you
>> Luke
>> 
>> On Tue, Sep 27, 2022 at 11:02 PM David Arthur 
>> wrote:
>> 
>>> Hey folks, I'd like to start a vote on KIP-868. This proposal adds
>>> lightweight transactions to the KRaft controller. These transactions
>>> will allow us to generate atomic batches of records that exceed the
>>> current limits of the metadata layer.
>>> 
>>> Here is the KIP:
>>> 
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-868+Metadata+Transactions
>>> 
>>> And previous discussion:
>>> https://lists.apache.org/thread/895pgb85l08g2l63k99cw5dt2qpjkxb9
>>> 
>>> Thanks to all who have reviewed so far!
>>> 
>>> Cheers,
>>> David
>>>