-
Notifications
You must be signed in to change notification settings - Fork 325
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
[all] support contexts #1170
Comments
@jayshrivastava Yes, you're right, it would be really good to take those contexts (and use them). The main difficulty, as in #1165, is how to do that without breaking compatibility. Or maybe, it would be a good opportunity to break compatibility, and change versioning scheme to 1.0. Would you like to drive a discussion on the [email protected] mailing list about this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The library does not take a context/context.
Describe the solution you'd like
I expect clients and producers to take a context argument upon creation and have all goroutines created by the clients and producers take a context as well. This is important for tracing (see https://medium.com/swlh/distributed-tracing-for-go-microservice-with-opentracing-1fc1aec76b3e). The context needs to be piped into all goroutines for observability.
It's also important to select on
ctx.Done()
when sending or recieving to channels. The libary does not do that at the moment. Ex.What if the command chan is full and
cp
cannot be send? This method will block. It would be beneficial to also select on a context provided by the user of the library in case the caller wants to cancel long running blocked operations.pulsar-client-go/pulsar/producer_partition.go
Lines 1462 to 1473 in f476814
The text was updated successfully, but these errors were encountered: