Redis cache: make blocking executions unordered

[Ladicek]

When the Redis cache is invoked from an ordered Vert.x blocking execution, which happens for example with SmallRye GraphQL or with chained caching (one blocking @CacheResult method invoking other blocking @CacheResult method), the Redis cache ends up hanging. This is because the next execution cannot start until the previous execution finishes, but the previous execution waits for the next execution.

This commit fixes that by making the Redis cache blocking executions unordered.

Fixes #39558
Fixes #42253

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 1fd2a9a.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[gsmet]

I don’t know this code at all but it feels dangerous to me to unorder cache calls execution, especially the writes.

[Ladicek]

@gsmet Right, so unordering here doesn't mean changing the order of operations expressed as Uni pipelines in the code. It refers to Vert.x executeBlocking()'s ordered parameter, which if set to true means that the [blocking] operations execute on the same thread; in other words, they are ordered. I believe that is wrong here, because if the caller of the @CacheResult method is already an ordered blocking execution, then we're effectively in a deadlock situation. The caller waits for the @CacheResult method to return, the @CacheResult method waits for the blocking execution to proceed, and it cannot, because it never gets its chance. By unordering the @CacheResult calls, we make sure they can [and will] be executed on different threads, preventing the deadlock. Hope that helps.

[gsmet]

Sounds a bit less scary but maybe let’s wait for @cescoffier ? :)

[Ladicek]

I'm not merging this, but note that @cescoffier has already approved :-)

[gsmet]

I have a filter hiding approvals made by people on PTO :).

[gsmet]

Now the big question: should it end up in 3.14?

[Ladicek]

One of the fixed bugs is on the 3.15 LTS board, but I'm fine with leaving this to 3.16 only, personally.

[gsmet]

@cescoffier I will let you judge of that and add the label for backport to 3.14 if you think that's how it should be done.

[cescoffier]

Added the label.

Here, things must be unordered, but don't worry, it's ordered elsewhere (there is a Redis "transaction").