recv: cap batch size at 5, default stays 1 (#2150 clarified)
This commit is contained in:
parent
ee45db6323
commit
78396c8189
6 changed files with 14 additions and 11 deletions
|
|
@ -152,11 +152,10 @@ pub(crate) const RECV_LONG_POLL_MAX: std::time::Duration = std::time::Duration::
|
|||
/// Server-side hard cap on `Recv.max`. Bounds the size of a single
|
||||
/// round-trip so a confused caller can't drain the entire inbox in
|
||||
/// one go and blow past wire-buffer sizes; everything above the cap
|
||||
/// silently clamps. 32 is comfortably above the burst sizes we've
|
||||
/// seen in practice (post-rebuild rescue, multi-agent reply storms)
|
||||
/// and well under the per-message `MESSAGE_MAX_BYTES` * N envelope
|
||||
/// budget.
|
||||
pub(crate) const RECV_BATCH_MAX: u32 = 32;
|
||||
/// silently clamps. 5 keeps individual turns small — a big backlog
|
||||
/// is drained over several recv calls instead of one giant pop
|
||||
/// (#2150).
|
||||
pub(crate) const RECV_BATCH_MAX: u32 = 5;
|
||||
|
||||
pub(crate) fn recv_timeout(wait_seconds: Option<u64>) -> std::time::Duration {
|
||||
match wait_seconds {
|
||||
|
|
|
|||
Loading…
Reference in a new issue