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

With KEY ordering, option to combine queues from different partitions or topics #314

Open
astubbs opened this issue May 24, 2022 · 3 comments
Assignees

Comments

@astubbs
Copy link
Contributor

astubbs commented May 24, 2022

In key mode, if records of a given key exist in

  • multiple partitions of a topic (and those partitions are assigned to me)
  • or when subscribing to multiple topics which have matching keys, have an option to have these either combined into a single queue, or kept separate.

If combined, option to choose how records are ordered relatively - e.g. via time stamp extractor, offset or publish time stamp.

Related:

@astubbs astubbs self-assigned this Jul 11, 2022
astubbs added a commit that referenced this issue Jul 12, 2022
…ic to shard key (#315)

- Try to reproduce issue #184 - run against multiple topics
- Introduce ShardKey
- Test for null keys in KEY ordering - records get queued into a null key queue - see #314
@phanivankadari
Copy link

We are looking at similar use case where we have multiple topics (for prioritization and fairness usecases) and we wanted key grouping across all topics related to a microservice (wildcard topic or list of topics specified). I suppose the current key grouping is supported to work for messages for a given key at a single partition level - is this assumption correct?

I see the PR is closed as stale but did not have much comments if had any other issues. Any updates on the feasibility of this feature request?

@JorgenRingen
Copy link
Contributor

Any plans to implement this i the near future? :-)

@rkolesnev
Copy link
Contributor

rkolesnev commented Oct 21, 2024

Not really - it would be quite niche feature with a lot of caveats - main one - there is really no easy and bulletproof way to guarantee deterministic ordering of messages with same key when consumed from different topics across rebalances, subscription changes - even poll batching / sizing may play a role in how messages are read from the topics and ultimately sequenced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants