Hello,
My name is Cheng Tan and I’m working at Confluent. Can I get the create content
permission so I can create a KIP? Thank you.
Best, - Cheng Tan
It’s d8tltanc. Thank you,
> On Mar 6, 2020, at 9:35 AM, Matthias J. Sax wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> What is your wiki account id?
>
> - -Matthias
>
> On 3/5/20 2:15 PM, Cheng Tan wrote:
>> Hello,
>>
>> M
KIP-576:+Support+dynamic+update+of+more+configs+related+to+replication>
Please feel free to discuss and suggest any other broker configs worth making
dynamic. Thanks.
Regards, - Cheng Tan
tps://cwiki.apache.org/confluence/display/KAFKA/KIP-593:+Enable+--if-exists+and+--if-not-exists+for+AdminClient+in+TopicCommand>
Thanks,
- Cheng Tan
let me know if you have any thoughts or suggestions. Thanks.
Best, - Cheng Tan
Hi Colin. Thanks for the discussion and feedback. I re-wrote the KIP-601
proposal following your suggestions. Now the new proposal is ready.
Best, - Cheng Tan
> On Apr 28, 2020, at 2:55 PM, Colin McCabe wrote:
>
>
> Thanks again for the KIP. This seems like it has been a gap in Kaf
the timeout in poll() or anywhere else might need an extra
iteration of all nodes, which might downgrade the network client performance.
I also updated the KIP content and KIP status. Please let me know if the above
ideas make sense. Thanks.
Best, - Cheng Tan
> On May 4, 2020, at 5:26 PM, Co
XMYkgh77k=,iterations=4096]
Please let me know what you think.
Best, - Cheng Tan
> On Apr 30, 2020, at 11:16 PM, Colin McCabe wrote:
>
>
ithin the request timeout to the leader?
>
> Regards,
>
> Rajini
>
>
>> On Thu, May 7, 2020 at 11:51 PM Jose Garcia Sancio
>> wrote:
>> Cheng,
>> Thanks for the KIP and the detailed proposal section. LGTM!
>>>> On Thu, May 7, 2020 at 3
would be the point? We were waiting in a
> queue for connecting, but we decide to stop and join the back of the queue.
>
> We have KIP-612 that is proposing to throttle connection set up on the one
> hand and this KIP that is dramatically reducing default connection timeout
> on th
Dear Rajini,
Thanks for all the feedbacks. They are very helpful for me to do the
brainstorming. I’ve incorporated our discuss in the KIP and started a voting
thread.
Best, - Cheng Tan
> On May 15, 2020, at 2:13 PM, Rajini Sivaram wrote:
>
> Hi Cheng,
>
> I am fin
ket+connection+timeout+in+NetworkClient>
Best, - Cheng Tan
, which is useless. However, if we set the
socket.connection.setup.timeout = 8 or 16, the last try won’t get wasted since
1 + 2 + 4 = 7 and 1 + 2 + 4 + 8 = 15.
Please let me know what you think. Thanks.
Best, - Cheng Tan
> On May 18, 2020, at 1:32 PM, Coli
ower timeout (i.e. a timeout for leastLoadedNode)?
>
> Regards,
>
> Rajini
>
>> On Thu, May 14, 2020 at 5:00 AM Cheng Tan wrote:
>>
>> Hi Rajini,
>>
>> Thanks for the comments.
>>
>>> I think
>>> they started off as connectio
+1 (non-binding)
> On Mar 19, 2020, at 7:27 PM, Sanjana Kaundinya wrote:
>
> Ah yes that makes sense. I’ll update the KIP to reflect this.
>
> Thanks,
> Sanjana
>
> On Thu, Mar 19, 2020 at 5:48 PM Guozhang Wang wrote:
>
>> Following the formula you have in the KIP, if it is simply:
>>
>>
clients.
Would appreciate any feedback on this. Thanks.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-580%3A+Exponential+Backoff+for+Kafka+Clients
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-580:+Exponential+Backoff+for+Kafka+Clients>
Best, - Cheng Tan
I think more about the potential wider use cases, I modified the proposal to
target all the connection. Thanks.
- Best, - Cheng Tan
> On May 7, 2020, at 1:41 AM, Cheng Tan wrote:
>
> Hi Colin,
>
> Sorry for the confusion. I’m proposing to im
the reconnect backoff. The existing
property ClusterConnectionStates.NodeConnectionState.lastConnectAttemptMs can
help us pick the LRU node conveniently. Does this make sense to you?
Please let me know what you think. Thanks.
Best, - Cheng Tan
> On May 19, 2020, at 1:44 PM, Colin McCabe wr
est+delivery+guarantee+by+default>
Thanks
- Cheng Tan
normal topics and won’t affect
the messaging functionality (produce, consume, transaction, etc), unoptimized
log configurations won’t harm the cluster.
Please let me know what you think. Thanks.
Best, - Cheng Tan
> On Aug 14, 2020, at 7:44 AM, David Arthur wrote:
>
> Cheng,
client created
internal topics.
To solve this pain point, I'm proposing support for clients to register and
query their own internal topics.
Please feel free to join the discussion. Thanks in advance.
Best, - Cheng Tan
= true
> right now? Does it fail? If not, that seems like a potential problem.
I also added this compatibility issue in the "Compatibility, Deprecation, and
Migration Plan" section.
Please feel free to make any suggestions or comments regarding to my latest
proposal.
s again for the long feedback and I’m always enjoying them. I’ve
supplement the above discussion into the KIP proposal. Please let me know what
you think.
Best, - Cheng Tan
> On Jun 2, 2020, at 3:01 AM, Rajini Sivaram wrote:
>
> Hi Cheng,
>
> Not sure if the discussion should move
The KIP is approved upon 3 binding votes. Thanks for all the feedback and votes!
- Cheng
Hi Chia,
Hope you are doing well. I already took KIP-619 as my KIP identification
number. Could you change your KIP id? Thank you.
Best, - Cheng
> On May 31, 2020, at 8:08 PM, Chia-Ping Tsai wrote:
>
> hi All,
>
> This KIP plans to deprecate two unused methods without replacement.
>
> All
+will+enable+the+strongest+delivery+guarantee+by+default
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-679:+Producer+will+enable+the+strongest+delivery+guarantee+by+default>
Please vote in this mail thread.
Thanks
- Cheng Tan
Hi Ismael,
Yes. Add deprecation warning for `IDEMPOTENT_WRITE` in 3.0 makes sense. I’ve
updated the KIP’s “DEMPOTENT_WRITE Deprecation” section to reflect your
suggestion. Please let me know if you have more suggestions. Thanks.
Best, - Cheng Tan
> On Dec 7, 2020, at 6:42 AM, Ismael J
ote:
>
>> Thanks, +1 (binding).
>>
>> On Mon, Dec 7, 2020 at 1:40 PM Cheng Tan wrote:
>>
>>> Hi Ismael,
>>>
>>> Yes. Add deprecation warning for `IDEMPOTENT_WRITE` in 3.0 makes sense.
>>> I’ve updated the KIP’s “DEMPOTENT_WRITE Depr
One thing I can think of is the ACL operations (create / delete ACLs). They are
much more less frequently used other than the produce/consume/topic creation so
I’m not sure if it’s valuable to use as a benchmark.
- Cheng
> On Nov 11, 2020, at 4:33 PM, Leonid Mesnik wrote:
>
> Hi Ismael
>
>
of
org.apache.kafka.server.authorizer.Authorizer#authorizeAny, now it’s not
coupled with org.apache.kafka.server.authorizer.Authorizer#authorize any more
and having a better performance.
Please feel free to comment and leave any thoughts. Any feedback will be
appreciated. Thanks.
Best, - Cheng
> On Oct 19, 2020, at 9:15 PM, Cheng
Cheng Tan created KAFKA-9591:
Summary: Log clearer error messages when there is an offset out of
range (Client Change)
Key: KAFKA-9591
URL: https://issues.apache.org/jira/browse/KAFKA-9591
Project: Kafka
Cheng Tan created KAFKA-9683:
Summary: Support dynamic update of
fetch.max.bytes/failed.authentication.delay/replica.fetch.response.max.bytes/replica.fetch.wait.max.ms/follower.replication.throttled.replicas/leader.replication.throttled.replicas
Cheng Tan created KAFKA-9862:
Summary: Enable --if-exists and --if-not-exists for AdminClient in
TopicCommand
Key: KAFKA-9862
URL: https://issues.apache.org/jira/browse/KAFKA-9862
Project: Kafka
Cheng Tan created KAFKA-9893:
Summary: Configurable TCP connection timeout for AdminClient
Key: KAFKA-9893
URL: https://issues.apache.org/jira/browse/KAFKA-9893
Project: Kafka
Issue Type: New
Cheng Tan created KAFKA-9800:
Summary: [KIP-580] Admin Client Exponential Backoff Implementation
Key: KAFKA-9800
URL: https://issues.apache.org/jira/browse/KAFKA-9800
Project: Kafka
Issue Type
Cheng Tan created KAFKA-9954:
Summary: Config command didn't validate the unsupported user
config change
Key: KAFKA-9954
URL: https://issues.apache.org/jira/browse/KAFKA-9954
Project: Kafka
Cheng Tan created KAFKA-9942:
Summary: --entity-default flag is not working for alternating
configs in AdminClient
Key: KAFKA-9942
URL: https://issues.apache.org/jira/browse/KAFKA-9942
Project: Kafka
Cheng Tan created KAFKA-9980:
Summary: Reserved word "" may not be santinized to
"%3Cdefault%3E"
Key: KAFKA-9980
URL: https://issues.apache.org/jira/browse/KAFKA-9980
Project: Kafka
Cheng Tan created KAFKA-9959:
Summary: leastLoadedNode() does not provide a node fairly
Key: KAFKA-9959
URL: https://issues.apache.org/jira/browse/KAFKA-9959
Project: Kafka
Issue Type: Bug
Cheng Tan created KAFKA-10619:
-
Summary: Producer will enable EOS by default
Key: KAFKA-10619
URL: https://issues.apache.org/jira/browse/KAFKA-10619
Project: Kafka
Issue Type: Improvement
Cheng Tan created KAFKA-13026:
-
Summary: Idempotent producer (KAFKA-10619) follow-up
Key: KAFKA-13026
URL: https://issues.apache.org/jira/browse/KAFKA-13026
Project: Kafka
Issue Type
41 matches
Mail list logo
