-
Notifications
You must be signed in to change notification settings - Fork 100
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
bitswap(client/messageque): expose donthavetimeout config #703
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #703 +/- ##
==========================================
- Coverage 60.35% 60.33% -0.03%
==========================================
Files 243 243
Lines 31038 31051 +13
==========================================
Hits 18734 18734
- Misses 10637 10648 +11
- Partials 1667 1669 +2
|
c9ca8a0
to
d04bd72
Compare
activeWants: make(map[cid.Cid]*pendingWant), | ||
timeout: cfg.DontHaveTimeout, | ||
messageLatency: &latencyEwma{alpha: cfg.MessageLatencyAlpha}, | ||
onDontHaveTimeout: onDontHaveTimeout, |
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.
The onDontHaveTimeout
function seems to accompany the config
is many/most places. So, onDontHaveTimeout
callback may be a candidate for moving into the DontHaveTimeoutConfig
type.
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.
I guess the question is: "Do we want users to register a custom handler there?". I would be opposed to that unless there is a prominent use case.
func defaultDontHaveTimeoutConfig() *DontHaveTimeoutConfig { | ||
cfg := &DontHaveTimeoutConfig{ | ||
DontHaveTimeout: 5 * time.Second, | ||
MaxExpectedWantProcessTime: 2 * time.Second, | ||
PingLatencyMultiplier: 3, | ||
MessageLatencyAlpha: 0.5, | ||
MessageLatencyMultiplier: 2, | ||
} | ||
|
||
cfg.MaxTimeout = cfg.DontHaveTimeout + cfg.MaxExpectedWantProcessTime | ||
return cfg |
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.
Two concerns with this approach:
- We expose a way for overriding the defaults without exposing the implicit default values themselves
- people will keep hardcoding current values instead of referencing const that may change in the future
- We use a struct which forces override fo all values
- This makes it tedious to override a single value
- This means if we add a new knob, people who already override the struct will override default with implicit zero value for that type (likely causing bugs)
My mental model for makign things like this configurable is to
- have
WithFoo
configuration options which allow overriding each knob individually - and expose
DefaultFoo
to allow people to programmatically refer to implicit default, rather than hardcoding them in their own code.
This may be more work in this PR upfront, but will save us from headache in the future. Thoughts?
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.
I suggest we expose the default struct for people to override necessary knobs this way:
cfg := DefaultDontHaveTimeoutConfig()
// example of granular customization
cfg.MaxExpectedWantProcessTime = 5 * time.Second
// use the global option.
WithDontHaveTimeoutConfig(cfg)
This solves your concern without creating "options hell". This is equivalent to having multi-level options, yet it's cleaner. Also, it doesn't require forwarding all the options from client
to bitswap
in case you want to add more options horizontally, which I tried initially, and got lost.
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.
Basically, the compromise I propose it expose the default configuration solving your concern while keeping things straightforward.
@gammazero, @lidel, one thing I realized about this component is that it's actually never disabled. The option to disable donthavetimeout handling exists in bitswap. However, it simply makes the handler no-op, while the component is still active and running, doing work that is costly (measuring latency, firing timeouts in routines, etc). And disabled donthavetimeout is the default behaviour in Kubo. |
Triage notes:
|
Closes #701