Add support for cooperative-sticky assignment strategy #339
Conversation
bestie
changed the base branch from
bestie/integration-test-performance
to
master
bestie
force-pushed
the
bestie/cooperative-sticky-assignment
branch
from
7291975
to
18bfabe
Compare
bestie
force-pushed
the
bestie/cooperative-sticky-assignment
branch
4 times, most recently
from
f12e4a2
to
4255529
Compare
Features: - Support for cooperative-sticky assignment strategy - Consumer class partition assign and revoke callbacks Tests: - Refactor to share a common consumer - Consistent and performant communication mechanism with test consumers (using pipes)
bestie
force-pushed
the
bestie/cooperative-sticky-assignment
branch
from
4255529
to
b7bdab4
Compare
|
The changes in this PR looks good. But there is reported issue about cooperative sticky failing with a crash on close prior to first rebalance. Deep dive and some suggestion fix here: confluentinc/librdkafka#4312 |
Just a reminder that my karafka OSS code is released under LGPL and not MIT (talking about karafka, not rdkafka-ruby or waterdrop). |
|
ah and this is a bypass. 2.2.1 librdkafka should be the one to include the correct fix and then it should be "passed" on to rdkafka-ruby via a dep bump. |
This provides an easier to use and more maintainable API by abstracting rdkafka methods and objects. rdkafka objects are available if necessary but discouraged via double underscore prefix.
bestie
force-pushed
the
bestie/cooperative-sticky-assignment
branch
from
9186de5
to
3ad7680
Compare
|
@deepredsky FYI there's going to be a 2.3.0 librdkafka release with the fix coming soon. I will bring it to rdkafka-ruby as soon as it reaches 2.3.1. |
|
@deepredsky just a heads up: 2.3.0 has been released. I should ship 0.14.0 rdkafka-ruby in the upcoming weeks once I test it fully. All should be good then. |
Features:
Tests: