gin-contrib / gin-contrib/cache
Unable to create shared cache for several instances of the same http-service
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 456
- Forks
- 100
- Avg merge
- 2h 16m
- Merged PRs (30d)
- 2
Description
Hello.
We are running a several instances of a service with shared redis-cache and we found some concurrency problems.
If I understood the logic correctly, it is like this:
- Check the cache.
- If there is a cached value, then return it.
- If not, then create a writer and run handler.
- When handler is done, write response to cache.
- The most unobvious part: if there is a cached value (so it must have appeared during step 3), append the current response data to it, instead of overwriting it.
https://github.com/gin-contrib/cache/blob/6b4ffed64d167edff23695c7bd60af88a6792120/cache.go#L84-L86 - ???
- PROFIT
So, when we send two equal queries and our balancer sends them to different instances, we will get the problem, mentioned in this closed issue: https://github.com/gin-contrib/cache/issues/15 Because two instances will both run handlers and the first one to finish will add the value to the cache and the second one will append it again.
What is the logic behind step 5? Maybe, we are using this lib incorrectly?
Thank you.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read cache.go around lines 84-86 and compare the behavior with the closed issue #15. Reproduce two equal requests against separate service instances using the shared Redis cache, then establish the expected result and document or test the behavior so completion is verifiable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, redis
- Domain
- backend, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100