-
Notifications
You must be signed in to change notification settings - Fork 339
Various AsyncProducer improvements #855
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
Conversation
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.
Thanks! Just a minor change needed.
spec/async_producer_spec.rb
Outdated
|
||
expect(async_producer.thread_mutex).to_not eq(async_producer2.thread_mutex) | ||
end | ||
end |
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 don't think we need a test for this – it's not testing functionality, but rather implementation details.
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.
Fixed up in 5f22fbd
Currently we reuse the same mutex for every instance of `AsyncProducer`. This means that one producer can block another producer from producing if it holds the mutex. This is unnecessary because the details of whether a particular producer's threads are running are irrelevant to every other producer.
There's no need to grab the mutex twice.
This is in preparation for a future change which will add another call to these methods and we don't want to duplicate the code.
We don't need to grab the mutex if both threads are still alive. But if we _do_ need to grab the mutex (i.e., if either/both of the threads are no longer alive), we'll need to re-check that the threads are alive later since someone else may have already restarted them by the time we've grabbed the mutex.
Currently if the worker thread has died unexpectedly and we subsequently call `deliver_messages`, the messages won't actually get delivered until another message is produced. With this change we will restart the worker thread so it can receive the `deliver_messages` message.
Similar to the previous commit, if a worker thread unexpectedly dies with unhandled messages in its queue and then we try to call `shutdown`, those messages won't be handled unless `produce` is called in the future (in which case the worker thread will read the `shutdown` message enqueued here and then exit again). With this change we will restart the worker thread so it can receive the `shutdown` message.
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.
Thanks!
See the commit messages for details.