Skip to content

Commit d358a24

Browse files
craig[bot]stevendanna
andcommitted
Merge #154121
154121: rangefeed: fix mangled comment r=wenyihu6 a=stevendanna This comment went through a few revisions and I mangle it when rebasing. Epic: none Release note: None Co-authored-by: Steven Danna <[email protected]>
2 parents cb0be5f + 51aa575 commit d358a24

File tree

1 file changed

+8
-6
lines changed

1 file changed

+8
-6
lines changed

pkg/kv/kvserver/rangefeed/buffered_sender.go

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -50,21 +50,23 @@ import (
5050

5151
// RangefeedSingleBufferedSenderQueueMaxSize is the maximum number of events
5252
// that the buffered sender will buffer before it starts returning capacity
53-
// exceeded errors. Updates to this setting are only applied to need
54-
// MuxRangefeedCalls, existing streams will use the previous value until
53+
// exceeded errors. Updates to this setting are only applied to new
54+
// MuxRangefeedCalls. Existing streams will use the previous value until
5555
// restarted.
5656
//
57-
// # The main goal of this limit is to provide a backstop against the
58-
//
59-
// The default here has been somewhat arbitrarily chosen considering that:
57+
// The default here has been arbitrarily chosen. Ideally,
6058
//
6159
// - We want to avoid capacity exceeded errors that wouldn't have occurred
6260
// when the buffered registrations were in use.
6361
//
6462
// - We don't want to drastically increase the amount of queueing allowed for a
6563
// single registration.
6664
//
67-
// - One buffered sender is feeding a single gRPC client.
65+
// A small buffer may be justified given that:
66+
//
67+
// - One buffered sender is feeding a single gRPC client, so scaling based on
68+
// registrations doesn't necessarily make sense. If the consumer is behind, it
69+
// is behind.
6870
//
6971
// - Events emitted during catchup scans have their own per-registration buffer
7072
// still.

0 commit comments

Comments
 (0)