-
Notifications
You must be signed in to change notification settings - Fork 172
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
#239 integrate sarama consumer group #260
Conversation
frairon
commented
Jul 8, 2020
- integrate sarama consumer group
- remove sarama-cluster dependency
Co-authored-by: R053NR07 <jan.bickel@lovoo.com>
updated readme for configuration, added changelog
Open Storage in PartitionTable when performing Setup
return trackOutput if stats are nil
added lots of godoc fixed many linter errors added Open call when creating storage
added lots of godoc, fixed many linter errors, added Open call when c…
stats-tracking improved
added strings to streams helper
Add Backoff when restartable CatchupForever is executed
Panic documentation & Migration guide
…wn the signal/observers, created example
248 connection state
Hello @frairon, |
Hi @fkarakas, you mean the support for the C implementation of kafka (I think it was based on librdkafka?), right? The thing was, that this implementation follows a completely different logic to rebalance and receive messages. In the "old" goka version, we had to do quite some magic to support both sarama and librdkafka, so it was very hard to understand, maintain, and it behaved flaky in an unstable kafka cluster. So we decided to simplify the logic and get rid of it for now. |
Thanks, if i understand correctly it was difficult to make an abstraction in the goka API which can both work with confluent and sarama because internally they work differently |
Yep exactly, and the point of the refactoring was to simplify things, get rid of sarama-cluster. Are you using the confluent api? |
Yes we are using the confluent lib, as you mentioned it is based on the C librdkafka so it is not a full GO lib which can be a stopper for go purist, but we decided to use it because it is confluent official lib for GO so we think it is "safer" regarding its maintenance/upgrade in the future ... |
That sounds like a reasonable choice. So is this a blocker for you to upgrade to a new goka version? And would you have the resources to look into it? |
Hey @fkarakas, Regarding the support. Sure librdkafka may get longer support but even if sarama would be deprecated today we would be able to integrate and switch to librdkafka; for us the effort would be almost the same then designing goka with interchangeable kafka libs. But still. If that's a blocker for you and others we can talk about changing this in future releases. |