gin-contrib / gin-contrib/cache

Unable to create shared cache for several instances of the same http-service

Open
#32 0 comments 2 reactions 0 assignees View on GitHub

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:

  1. Check the cache.
  2. If there is a cached value, then return it.
  3. If not, then create a writer and run handler.
  4. When handler is done, write response to cache.
  5. 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
  6. ???
  7. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.