Hi Anna,
Thank you for your answers.
900. Sorry, I forgot the connection creation rate metric already
allows users to detect excessive rates. I agree per-IP metrics would
expose to a high-cardinality risk.
902. Thank you for the pointers. I will explore the existing stress
test in Trogdor.
Thank
I realized the KIP freeze is on May 20. I will start the voting thread now.
On Mon, May 18, 2020 at 3:19 PM Anna Povzner wrote:
> Thanks everyone for the feedback. I will start a voting thread tomorrow
> morning if there are no more comments.
>
> Regards,
> Anna
>
> On Mon, May 18, 2020 at 2:06
Thanks everyone for the feedback. I will start a voting thread tomorrow
morning if there are no more comments.
Regards,
Anna
On Mon, May 18, 2020 at 2:06 PM Anna Povzner wrote:
> Hi Boyang,
>
> This KIP does not change the protocol with clients. The behavior is the
> same as with KIP-402 where
Hi Boyang,
This KIP does not change the protocol with clients. The behavior is the
same as with KIP-402 where the broker delays accepting new connections when
the limit for the number of connections is reached. This KIP adds another
reason for the delay (when the rate is reached). Similarly, when
Hey Anna,
thanks for the KIP. Will this change be applied as one type of quota
violation, which for client side should be retriable? For EOS model before
2.6, the Streams client creates one producer for each input partition, so
it is actually possible to create thousands of producers when the serv
Hi Alexandre,
Thanks for your comments. My answers are below:
900. The KIP does not propose any new metrics because we already have
metrics that will let us monitor connection attempts and the amount of time
the broker delays accepting new connections:
1. We have a per-listener (and per-processor
Hi Anna,
Thanks for the response, sounds good.
Regards,
Rajini
On Sun, May 17, 2020 at 1:38 AM Anna Povzner wrote:
> Hi Rajini,
>
> Thanks for reviewing the KIP!
>
> I agree with your suggestion to make per-IP connection rate quota a dynamic
> quota for entity name IP. This will allow config
Hi Rajini,
Thanks for reviewing the KIP!
I agree with your suggestion to make per-IP connection rate quota a dynamic
quota for entity name IP. This will allow configuring connection rate for a
particular IP as well. I updated the wiki accordingly.
Your second concern makes sense -- rejecting the
Hi Anna,
Thank you for your answers and explanations.
A couple of additional comments:
900. KIP-612 does not intend to dedicate a metric to the throttling of
incoming connections. I wonder if such a metric would be handy for
monitoring and help set-up metric-based alarming if one wishes to
captu
Hi Anna,
Thanks for the KIP, looks good overall. A couple of comments about per-IP
connection quotas:
1) Should we consider making per-IP quota similar to other quotas?
Configured as a dynamic quota for entity type IP, with per-IP limit as well
as defaults? Perhaps that would fit better rather th
Hi Anna,
Thanks for your answers and the updated KIP. Looks good to me!
Best,
David
On Thu, May 14, 2020 at 12:54 AM Anna Povzner wrote:
> I updated the KIP to add a new broker configuration to limit connection
> creation rate per IP: max.connection.creation.rate.per.ip. Once the limit
> is re
I updated the KIP to add a new broker configuration to limit connection
creation rate per IP: max.connection.creation.rate.per.ip. Once the limit
is reached for a particular IP address, the broker will reject the
connection from that IP (close the connection it accepted) and continue
rejecting them
Hi David and Alexandre,
Thanks so much for your feedback! Here are my answers:
1. Yes, we have seen several cases of clients that create a new connection
per produce/consume request. One hypothesis is someone who is used to
connection pooling may accidentally write a Kafka client that creates a n
Hello,
Thank you for the KIP.
I experienced in the past genuine broker brownouts due to connection
storms consuming most of the CPU available on the server and I think
it is useful to protect against it.
I tend to share the questions asked in points 2 and 4 from David. Is
there still a risk of d
Hi Anna,
Thanks for the KIP! I have few questions:
1. You mention that some clients may create a new connections for each
requests: "Another example is clients that create a new connection for each
produce/consume request". I am curious here but do we know any clients
behaving like this?
2. I am
Hi,
I just created KIP-612 to allow limiting connection creation rate on
brokers, and would like to start a discussion.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-612%3A+Ability+to+Limit+Connection+Creation+Rate+on+Brokers
Feedback and suggestions are welcome!
Thanks,
Anna
16 matches
Mail list logo
