-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
fix(memcached): panic on send on closed channel
.
#7817
fix(memcached): panic on send on closed channel
.
#7817
Conversation
Our memcached client has race between closing `inputCh` and submitting work to it (writing to channel) by different goroutines. This PR fix it by having `closed` channel to track if `inputCh` is closed and make it visible to other writter go-routines. Before: ``` === RUN TestMemcached_fetchKeysBatched panic: send on closed channel goroutine 29 [running]: github.com/grafana/loki/pkg/storage/chunk/cache.(*Memcached).fetchKeysBatched.func1() /home/kavirajk/src/loki/pkg/storage/chunk/cache/memcached.go:167 +0x87 created by github.com/grafana/loki/pkg/storage/chunk/cache.(*Memcached).fetchKeysBatched /home/kavirajk/src/loki/pkg/storage/chunk/cache/memcached.go:164 +0x165 FAIL github.com/grafana/loki/pkg/storage/chunk/cache 0.015s FAIL ``` After: ``` loki$ go test -v ./pkg/storage/chunk/cache/... -run TestMemcached_fetchKeysBatched === RUN TestMemcached_fetchKeysBatched --- PASS: TestMemcached_fetchKeysBatched (0.00s) PASS ok github.com/grafana/loki/pkg/storage/chunk/cache 0.013s ``` Signed-off-by: Kaviraj <[email protected]>
Signed-off-by: Kaviraj <[email protected]>
b21bfc0
to
5ae4ab3
Compare
Signed-off-by: Kaviraj <[email protected]>
./tools/diff_coverage.sh ../loki-target-branch/test_results.txt test_results.txt ingester,distributor,querier,querier/queryrange,iter,storage,chunkenc,logql,loki Change in test coverage per package. Green indicates 0 or positive change, red indicates that test coverage for a package fell. + ingester 0%
+ distributor 0%
+ querier 0%
+ querier/queryrange 0%
+ iter 0%
+ storage 0%
+ chunkenc 0%
+ logql 0%
+ loki 0% |
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.
Great find @kavirajk!
Follow up to #7817 This PR uses `default` branch instead of `inputCh <- work` to make sure we are writing to closed `inputCh`. Signed-off-by: Kaviraj <[email protected]>
) Signed-off-by: Kaviraj <[email protected]> **What this PR does / why we need it**: Follow up to #7817 This PR uses `default` branch instead of `inputCh <- work` to make sure we are writing to closed `inputCh`. Gist is, `default` run [only when none of the branch is ready](https://go.dev/tour/concurrency/6). which makes more sense rather than to have `inputCh <- work` (writing to closed channel on the branch condition) These can be explained by these two tiny snippets. * [with `default`](https://go.dev/play/p/-FspbTZd20I) * [without `default`](https://go.dev/play/p/Ag4WznOaEq0) **Which issue(s) this PR fixes**: Fixes #NA **Special notes for your reviewer**: We already have test `TestMemcached_fetchKeysBatched` to catch this behaviour. In fact this test caught this probabilistic behaviour in some CI failures. [here ](https://drone.grafana.net/grafana/loki/17853/3/4) and[ here](https://drone.grafana.net/grafana/loki/17854/3/4) Thanks @DylanGuedes for catching this CI failures. **Checklist** Signed-off-by: Kaviraj <[email protected]>
What this PR does / why we need it:
Our memcached client has race between closing
inputCh
and submitting work to it (writing to channel) by different goroutines.This PR fix it by having
closed
channel to track ifinputCh
is closed and make it visible to other writter go-routines.Before:
After:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Found this panic on lots of internal Loki prod clusters.
Checklist
CHANGELOG.md
updated