-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review default values for configuration settings #187
Comments
Dear @TsuyoshiUshio, based on my observations at #186, I believe making However, getting the default values for the settings So, I am humbly asking you to focus on the
With kind regards, |
Hi @amotl The reason why I include I just want to achieve your goal. So I'd like to know the exact parameter should I add to achieve your goal. According to the https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md documentation, topic.metadata.refresh.interval.ms
Currently, we have these configuration for librdkafka In short, For achieve your goal. We need to make it configurable these parameters and you think it might be better to set it as default, right?
I agree with you we should make it default since the issue is hard to find and I suppose a lot of customer use this on Azure. The reason is, for this library, customer can choose the version by themselves. It will be breaking change however, a lot of use case is for azure. So I think I add the parameter on the releasenote and avoid the breaking change you can configure these parameters. I guess, that parameter doesn't affect a much. What do you think? @fbeltrao @ahmelsayed ? NOTE: Why we need it.
|
Dear @TsuyoshiUshio, thanks for considering to bring in the respective default values for the configuration properties which are of primary concern here. While I recognized However, as noted above, I believe the configuration properties
Exactly. Both setting these and upgrading to librdkafka 1.5.2 improved things tremendously for us. With kind regards, |
Thank you for helping me to understand! I'll implement it. For the breaking change part, I'll wait the other guys opinion. However, I'll add the properties at least. I also add the properties that is described as recommended for EventHubs. |
I investigate other properties however, all of them is already configured as the ideal configuration. I just add these two.
|
Dear @TsuyoshiUshio, that looks good so far. Thank you very much! With kind regards, |
Thanks a again for considering these improvements! Closing this now. |
Dear @TsuyoshiUshio and @fbeltrao,
firstly, I would like to apologize for bumping into the review process at #186 (comment) and #186 (comment). Let's better continue a more thorough discussion here.
As a followup to #185, I would like to dedicate this topic a separate issue regarding
As we found out recently, Microsoft published some recommended configuration properties for librdkafka at [1]. It would be nice if the Azure function bindings for Kafka would already use these recommendations out of the box. I didn't check the code base thoroughly yet, so I am humbly asking for your support on that for the upcoming release when the bump to librdkafka 1.5.2 will take place.
As outlined within [1], the configuration properties
socket.keepalive.enable
andmetadata.max.age.ms
are crucial to get right within Azure environments in order to save users from running into issues like outlined within confluentinc/librdkafka#3109. I strongly recommend to apply these default values out of the box as most regular users will not be aware of them and might experience nasty things.While these settings [1] are primarily dedicated to Event Hubs, they will also apply to all communications with vanilla Kafka server components, as the underlying networking infrastructure problem outlined within confluentinc/librdkafka#3109 will be the same.
Thanks for listening and with kind regards,
Andreas.
[1] https://docs.microsoft.com/en-us/azure/event-hubs/apache-kafka-configurations#librdkafka-configuration-properties
The text was updated successfully, but these errors were encountered: