-
Notifications
You must be signed in to change notification settings - Fork 26
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
Fix Kafka Client List Topics Method #88
Conversation
We will need a new release of this gem once this is merged |
native_kafka = producer.instance_variable_get(:@native_kafka) | ||
Rdkafka::Admin.new(native_kafka).metadata |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to use ::Rdkafka::Config#admin
method here rather than having to use instance_variable_get
, https://github.com/karafka/rdkafka-ruby/blob/main/lib/rdkafka/config.rb#L263-L286
native_kafka = producer.instance_variable_get(:@native_kafka) | |
Rdkafka::Admin.new(native_kafka).metadata | |
@kafka_client.admin.metadata |
@@ -69,6 +69,11 @@ def topics | |||
Rdkafka::Metadata.new(native_kafka).topics.collect { |topic| topic[:topic_name] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nasark I think we can use this method if we use:
Rdkafka::Metadata.new(native_kafka).topics.collect { |topic| topic[:topic_name] } | |
kafka_client.admin.metadata.topics.map { |topic| topic[:topic_name] } |
@@ -69,6 +69,11 @@ def topics | |||
Rdkafka::Metadata.new(native_kafka).topics.collect { |topic| topic[:topic_name] } | |||
end | |||
|
|||
def metadata |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "metadata" is a little vague and would be hard to implement for the other messaging types, where listing queues/topics could likely be done.
I think we'd be better off fixing the "topics" method above, possibly implement an alive?
method that catches Local: Broker transport failure (transport) (Rdkafka::RdkafkaError)
and returns false and we could use that for the health-check, wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we catch errors in the top level health check method which basically does the same thing https://github.com/ManageIQ/manageiq/blob/master/app/models/miq_server.rb#L632, or is it better to catch here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also in manageiq-messaging-ready https://github.com/ManageIQ/manageiq-appliance/blob/master/COPY/usr/bin/manageiq-messaging-ready#L35
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we catch errors in the top level health check method which basically does the same thing
Yeah that's fine for now, I don't like exposing "internal" exception classes like RdkafkaError
to the caller but we already do that elsewhere in this class. Ideally we'd catch RdkafkaError and wrap it in a ManageIQ::Messaging::Error class but that's a larger effort.
7d9446d
to
54bfcf3
Compare
Released v1.4.2 https://github.com/ManageIQ/manageiq-messaging/releases/tag/v1.4.2 with this change |
Follow up #89 |
This method uses the rdkafka admin API to retrieve metadata from the kafka server. This is a good way to perform health checks since if the kafka server is down, this will return an error instead.
@miq-bot assign @agrare
@miq-bot add_reviewer @agrare
@miq-bot add_label enhancement