queue: add new BackpressureQueue[T] variant #9838
Conversation
Roasbeef
added
enhancement
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Pull reviewers statsStats of the last 30 days for lnd:
|
queue/back_pressure.go
Outdated
| } | ||
|
|
||
| // Enqueue attempts to add an item to the queue, respecting context | ||
| // cancellation. Returns true if the item was dropped by the predicate, false if |
There was a problem hiding this comment.
I would expect the bool to be flipped, based on the method name.
Engueueing failed when the item was dropped, so I expect false.
There was a problem hiding this comment.
Perhaps we make this more explicit by returning an error?
There was a problem hiding this comment.
Modified to return an error instead.
| // For example, with minThreshold=15 and maxThreshold=35: | ||
| // - At queueLen=15, p=0.0 (0% drop chance) | ||
| // - At queueLen=25, p=0.5 (50% drop chance) | ||
| // - At queueLen=35, p=1.0 (100% drop chance) |
There was a problem hiding this comment.
Does it make sense to have a longer queue than maxTreshold? If messages get dropped with a 100% chance, the queue will never fill up after maxTreshold. If my understanding is correct we could infer masTreshold from the queue length.
There was a problem hiding this comment.
Hmm, that's a good point. I'd prefer to allow them to be passed in without constraint (outside of initial validation), then have the caller select the maxTreshold themselves, so it remains maximally configurable.
queue/back_pressure_test.go
Outdated
| t, res.IsOk(), "Enqueue of 42 should not error: %v", res.Err(), | ||
| ) | ||
| require.True(t, | ||
| res.UnwrapOrFail(t), "Item 42 should have been dropped by "+ |
There was a problem hiding this comment.
nit. I was confused, because this can never fail, since you checked res.IsOk() above. But we are checking the success case of the result, which should be true. Maybe consider res.UnwrapOr(false)?
There was a problem hiding this comment.
I think can remove the above check, and just have it be UnwrapOrFail.
In this commit, we add a new type of queue: the back pressure queue. This is a bounded queue based on a simple channel, that will consult a predicate to decide if we should preemptively drop a message or not. We then provide a sample predicate for this use case, based on random early dropping. Given a min and max threshold, we'll start to drop message randomly once we get past the min threshold, ramping up to the max threshold where we'll start to always drop the message.
Roasbeef
force-pushed
the
backpressure-queue
branch
from
2e346d0 to
3511604
Compare
|
Pushed up a new version. PTAL. |
|
@gijswijs: review reminder |
In this commit, we add a new type of queue: the back pressure queue. This is a bounded queue based on a simple channel, that will consult a predicate to decide if we should preemptively drop a message or not.
We then provide a sample predicate for this use case, based on random early dropping. Given a min and max threshold, we'll start to drop message randomly once we get past the min threshold, ramping up to the max threshold where we'll start to always drop the message.