-
Notifications
You must be signed in to change notification settings - Fork 23
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
ADR-42 consumer priority groups #279
Conversation
This is a draft, I have some work left to do here and some thinking but enough to get some feedback, i am not feeling too hot today but wanted to get this out, please discuss here. |
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.
Some comments and thoughts around details and future proofing.
cc: @bruth lots of hope to get this in 2.11 |
```go | ||
type PriorityGroupState struct { | ||
Group string `json:"name"` | ||
PinnedClientId string `json:"pinned_id,omitempty"` |
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.
SelectedClientId
LeaseTs
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.
LGTM - I put some suggestions on terms/option names
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.
Just some minor test edit suggestions, and some comments (things to be captured for when the documentation is going to be written based on this document). LGTM.
|
||
* We have 1 group defined and all pulls have to belong to this group | ||
* The policy is `pinned_client` that activates these behaviors | ||
* When a pinned client has not done any pulls in the last 120 seconds the server will switch to another client |
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.
With this approach, longer expire interval, more sensitive the TTL becomes.
Maybe we should base TTL on Duration since last Pinned Client Pull Request expiry?
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.
Might be an option, my thinking was that people will tune this based on their usage, network, maintenance behaviours etc rather than have a lot of magic.
We could move to magic in a future version though but I am reluctant to start with magic.
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.
FWIW in my initial consumer group implementation I am using the idle timeout for the consumer (i.e. time since last pull request expired) and it's working for me. Otherwise what if you set the timeout to for example 60s and the applications are fetching with a timeout of more than 60s, wouldn't that lead to flapping when there are no new messages to deliver?
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.
Maybe not clear here but like the way it calculates if a consumer is idle or not it wouldn’t consider a client with an flight pull as being active.
But this seems open to bugs or abuse so perhaps you simply would have to ensure you pull more frequently. Alternatively we could cap the pull timeout so it relates to this timeout - no more than twice this timeout pull expire or something?
good point. Needs some thinking here
fe31831
to
c504b6b
Compare
c504b6b
to
6a06327
Compare
7250d66
to
1f81756
Compare
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.
LGTM
1f81756
to
b88e77d
Compare
Signed-off-by: R.I.Pienaar <[email protected]>
24baa04
to
3c19129
Compare
No description provided.