Re: [DISCUSS] KIP-882: Make Kafka Connect REST API request timeouts configurable

Hi Sagar, Thanks for chiming in! > Having said that, why does the worker forward to the > leader? I am thinking if the worker can perform the validation on it's own, > we could let it do the validation instead of forwarding everything to the > leader Only the leader is allowed to perform writes

Re: [DISCUSS] KIP-882: Make Kafka Connect REST API request timeouts configurable

Hi Chris, Thanks again for your feedback. I think a worker configuration for the upper bound makes sense - I initially thought we could hardcode it (just like the current request timeout is), but there's no reason to set another artificial bound that isn't user configurable which is exactly what

[jira] [Created] (KAFKA-14359) Idempotent Producer continues to retry on OutOfOrderSequence error when first batch fails

Justine Olshan created KAFKA-14359: -- Summary: Idempotent Producer continues to retry on OutOfOrderSequence error when first batch fails Key: KAFKA-14359 URL: https://issues.apache.org/jira/browse/KAFKA-14359

[jira] [Created] (KAFKA-14358) Users should not be able to create a regular topic name __cluster_metadata

José Armando García Sancio created KAFKA-14358: -- Summary: Users should not be able to create a regular topic name __cluster_metadata Key: KAFKA-14358 URL:

Re: [DISCUSS] KIP-875: First-class offsets support in Kafka Connect

Hi Yash, Thanks again for your thoughts! Responses to ongoing discussions inline (easier to track context than referencing comment numbers): > However, this then leads me to wonder if we can make that explicit by including "connect" or "connector" in the higher level field names? Or do you think

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

Hi ShunKang, Thanks for the KIP! I’ve been wanting to transition toward byte buffers for a while, so this is a nice start. I thought it was a bit weird to flip the buffer inside the serializer, but I see the existing one already does that. I would have thought it would make more sense for

[jira] [Created] (KAFKA-14357) Make it possible to batch describe requests in the Kafka Admin API

Jakub Scholz created KAFKA-14357: Summary: Make it possible to batch describe requests in the Kafka Admin API Key: KAFKA-14357 URL: https://issues.apache.org/jira/browse/KAFKA-14357 Project: Kafka

[jira] [Created] (KAFKA-14356) Make it possible to detect changes to SCRAM-SHA credentials using the Admin API

Jakub Scholz created KAFKA-14356: Summary: Make it possible to detect changes to SCRAM-SHA credentials using the Admin API Key: KAFKA-14356 URL: https://issues.apache.org/jira/browse/KAFKA-14356

[jira] [Created] (KAFKA-14355) Integer overflow occurs in kafka-producer-perf-test.sh (class ProducerProfrmance ).

Minoru Tomioka created KAFKA-14355: -- Summary: Integer overflow occurs in kafka-producer-perf-test.sh (class ProducerProfrmance ). Key: KAFKA-14355 URL: https://issues.apache.org/jira/browse/KAFKA-14355

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #1335

See

Re: [DISCUSS] KIP-881: Rack-aware Partition Assignment for Kafka Consumers

Hi Viktor, I can actually answer your question. KIP-848 already includes rack awareness in the protocol. It is actually the other way around, this KIP takes the idea from KIP-848 to implement it in the current protocol in order to realize the benefits sooner. The new protocol will take a while to

Regarding Producer Metric - "request-latency-avg"

Hi, There is a producer metric ( request-latency-avg ), this is not updated in producer metrics documentation in

Re: [DISCUSS] KIP-881: Rack-aware Partition Assignment for Kafka Consumers

Hi Rajini, Thanks for the KIP. I have a few questions/comments: 01. If I understood correctly, the plan is to add new assignors which are rack aware. Is this right? I wonder if it is a judicious choice here. The main drawback is that clients must be configured correctly in order to get the

review request: #12753 (small pr)

Hello all, I'd love to get this reviewed and ideally merged, it's just adding some documentation around seek() that I would have found helpful while developing. The tests which are failing seem to be from a completely different part of the codebase (mostly around consensus mechanism).