bitswap(client/messageque): expose donthavetimeout config #703
Conversation
Wondertan
changed the title
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
|
Wondertan
force-pushed
the
donthavetimeoutconfig
branch
from
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.
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.
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.
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
WithFooconfiguration options which allow overriding each knob individually - and expose
DefaultFooto 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.
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.
Basically, the compromise I propose it expose the default configuration solving your concern while keeping things straightforward.
gammazero
added
need/author-input
|
@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:
|
lidel
added
need/author-input
gammazero
added
need/maintainers-input
|
I am planning on changing this to enable and configure onDontHaveTime using an option param. This will likely be done in a different PR. |
|
Feel free to close this one then |
|
Nvm, I'll just close it myself |
Closes #701