Skip to content
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

quarkus-cache might block indefinitely when backed by Redis and lockTimeout=0 #39558

Closed
lxngr opened this issue Mar 19, 2024 · 4 comments · Fixed by #42540
Closed

quarkus-cache might block indefinitely when backed by Redis and lockTimeout=0 #39558

lxngr opened this issue Mar 19, 2024 · 4 comments · Fixed by #42540
Labels
Milestone

Comments

@lxngr
Copy link

lxngr commented Mar 19, 2024

Describe the bug

When using qarkus-cache backed by quarkus-redis-cache and lockTimeout=0 the cache might block indefinitely. This is the case when a cache miss uses a "heavy weight" operation that itself uses a cache and that operation misses too (two chained cache misses).

Might not a be the best idea but works well when using the default cache implementation (Caffeine).

Expected behavior

The second "heavy weight" operation should be executed anyway and the cache should not block (like when using the default cache implementation).

Actual behavior

Cache blocks indefinitely.

How to Reproduce?

I've build an reproducer based on the cache example (APPLICATION DATA CACHING) that uses two caches chained and both miss: https://github.com/lxngr/quarkus-cache.

Test with: "curl http://localhost:8080/weather\?city\=LA"

Output of uname -a or ver

Darwin Kernel Version 23.4.0 (macOS)

Output of java -version

openjdk version "17.0.10" 2024-01-16 LTS

Quarkus version or git rev

3.8.2

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.2

Additional information

No response

@lxngr lxngr added the kind/bug Something isn't working label Mar 19, 2024
@quarkus-bot
Copy link

quarkus-bot bot commented Mar 19, 2024

/cc @cescoffier (redis), @gsmet (redis), @gwenneg (cache), @machi1990 (redis)

@geoand
Copy link
Contributor

geoand commented Mar 20, 2024

Interesting scenario.

You mention lockTimeout=0 in the description, but I don't see that configured anywhere in the sample application you have attached. Can you clarify?

@geoand geoand added the triage/needs-feedback We are waiting for feedback. label Mar 20, 2024
@lxngr
Copy link
Author

lxngr commented Mar 20, 2024

I've left it out in my sample application as lockTimeout = 0 is the default.

@geoand geoand removed the triage/needs-feedback We are waiting for feedback. label Mar 20, 2024
@geoand
Copy link
Contributor

geoand commented Mar 20, 2024

Ah, you're right.

I am not sure what we can really do about this one as it's a weird case...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging a pull request may close this issue.

3 participants