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

WebClient request sent twice instantly when using @Cacheable #32370

Closed
dor3no opened this issue Mar 4, 2024 · 4 comments
Closed

WebClient request sent twice instantly when using @Cacheable #32370

dor3no opened this issue Mar 4, 2024 · 4 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: bug A general bug
Milestone

Comments

@dor3no
Copy link

dor3no commented Mar 4, 2024

Hi all,

We started using the spring cache abstraction in our REST API. The methods we want to cache make an HTTP request to a third-party API using WebClient.

The issue occurs when the @Cacheable method returns a Flux, we can see in the logs that the HTTP request is submitted twice instantly. This does not happen when the method returns a Mono.

I was hoping to gain some understanding as to why this double call occurs and how to avoid this from happening?
Thanks for your input.

Using spring-boot 3.2.3, spring-webflux.
Here is a small project showing the issue: https://github.com/dor3no/cacheable-double-request

@dor3no dor3no changed the title WebClient request sent twice when using @Cacheable WebClient request sent twice instantly when using @Cacheable Mar 4, 2024
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 4, 2024
@simonbasle simonbasle self-assigned this Mar 5, 2024
@snicoll snicoll added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-feedback We need additional information before we can continue labels Mar 5, 2024
@simonbasle simonbasle added type: bug A general bug in: core Issues in core modules (aop, beans, core, context, expression) and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Mar 5, 2024
@simonbasle simonbasle added this to the 6.1.5 milestone Mar 5, 2024
@simonbasle
Copy link
Contributor

simonbasle commented Mar 5, 2024

I was able to reproduce this and will have a look at how we can improve puts in reactive caching support.

@dor3no
Copy link
Author

dor3no commented Mar 5, 2024

@snicoll @simonbasle
Thank you both for having a look.

@simonbasle
Copy link
Contributor

simonbasle commented Mar 5, 2024

The fix is done and additionally handles cases where the initial subscriber to the cacheable Flux does small incremental request(s) or cancels. For instance, if you use myCacheableFlux().take(3) the caching will not trigger an unbounded request to entirely consume the original Flux, but rather just stick to the 3 requested elements.

@simonbasle
Copy link
Contributor

thinking about it a bit more, I'm not satisfied with the above change. from a user perspective, this makes the caching a bit too nondeterministic... the number of elements cached would now actually depend not only on the operators used in the Flux-caching method but also on the operators / request pattern from the first actual subscription to said Flux.

with the example previously used (myCacheableFlux().take(3)), if a second call to the myCacheableFlux method is performed later like myCacheableFlux().collectList(), it will only reflect 3 elements even though the original Flux might have been capable of emitting many more.

I'll revert my change to get back to the previous behavior (exhausting the original Flux in a parallel subscription), with a different approach at fixing the issue.

@simonbasle simonbasle reopened this Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

4 participants