Skip to content
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

Kafka exception catch #55

Merged
merged 7 commits into from
Apr 1, 2022

Conversation

areeda
Copy link
Contributor

@areeda areeda commented Mar 17, 2022

This PR addresses issue #54.

It simply moves the consume call inside the try block in the _stream_forever method of the Consumer Class.
This allow the the main thread of the calling program to continue.

Joseph Areeda and others added 7 commits March 14, 2022 14:37
Add OAUTHBEARER / OpenID Connect (OIDC) support as described in
[KIP-768]. This is the authentication mechanism used by the
GCN/TACH Kafka broker.

* The `SASLMethod` enum gets a new member, `OAUTHBEARER`.
* The `SASLAuth` constructor gets a new optional keyword argument,
  `token_endpoint`.
* The presence of the `token_endpoint` keyword argument causes the
  default SASL method to change to `OAUTHBEARER` and the oauthbearer
  method to change to `oidc`, because this option is required for
  OpenID Connect and ignored for all other auth methods.
* In OIDC mode, the `username` and `password` positional arguments
  are interpreted as the client ID and client secret.

[KIP-768]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186877575
Copy link
Collaborator

@cnweaver cnweaver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this is a useful change: With it in place if there is a network disruption, the broker goes down, etc. the consumer will keep retrying, which if the problem is resolved allows it to pick up reading where it left off (particularly with use of a consumer group). It is something of a blunt instrument, in that it does not give the user/higher level code the option to assess the error and decide whether to continue, but I think that such a capability probably isn't needed? This may be an area to keep an eye on in future, in case there are some types of errors which should break out of the subscribe loop and bubble up.

@cnweaver cnweaver merged commit 0d38c10 into astronomy-commons:master Apr 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants