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 messages listener can use more kafka consumers than one #43

Merged
merged 2 commits into from
Aug 13, 2020

Conversation

onukristo
Copy link
Contributor

  • IKafkaMessageHandler Topics can now specify a shard. Every shard will have it's own KafkaConsumer and processing thread.
    It is useful in scenarios where low latency processing is desired for a specific topic.
    The downside of multiple shards is having more KafkaConsumers per application, possibly increasing the load on Kafka server.
  • tw-leader-selector was upgraded, it now brings in tw-curator.
    This in turn means, that you don't have to define a CuratorFramework bean in your application, it will be created
    automatically if missing.

…ll have it's own KafkaConsumer and processing thread.

It is useful in scenarios where low latency processing is desired for a specific topic.
The downside of multiple shards is having more KafkaConsumers per application, possibly increasing the load on Kafka server.
- tw-leader-selector was upgraded, it now brings in tw-curator.
This in turn means, that you don't have to define a CuratorFramework bean in your application, it will be created
automatically if missing.
@onukristo onukristo merged commit 150da4b into master Aug 13, 2020
@yevhenii0 yevhenii0 deleted the listener_shards branch November 9, 2020 09:52
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.

2 participants