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

Async Load All result is ignored when its size matches the cache size #655

Closed
jonathannaguin opened this issue Jan 24, 2022 · 5 comments
Closed

Comments

@jonathannaguin
Copy link

Hello,

When my application starts I want to fill the cache with items so I am running this:

var cache = Caffeine.newBuilder()
                             .refreshAfterWrite(Duration.ofMinutes(5))
                             .buildAsync(this);
cache.getAll(List.of("*")) .get();

Disclaimer: I can't use a empty list, otherwise the AsyncCacheLoader never gets invoked (see

if (proxies.isEmpty()) {
return composeResult(futures);
}
).

So my only option is to use a dummy key like "*", this works fine and my asyncLoadAll gets called and I can return a map of items.
The problem I have is when this method returns one single item as this piece of code assumes the entry returned is the same as the one used in the getAll invocation:

if (proxies.size() == result.size()) {
return;
}

@ben-manes
Copy link
Owner

Oh, that's a good catch. I agree that size comparison looks unnecessary and wrong. I was able to confirm your problem and fix in a unit test. My weekdays are hectic so more often I work on a release over the weekend, so hopefully I can get that to you by next Monday.

@jonathannaguin
Copy link
Author

Thanks a lot @ben-manes !

@ben-manes
Copy link
Owner

Hi @jonathannaguin,

I apologize but it looks like I won't be ready to release this weekend. I have been assisting two other teams privately which require have minor API changes in the `Cache.policy() extensions (one is a persistent and the other is a distributed cache). Those discussions and iterations have split my free time for this project. I'll try to make their changes over this coming week and have something ready soon.

In the meantime if this is causing trouble then you might either (a) return an extra dummy unreachable entry to skip this guard or (b) use jitpack.io to temporarily depend on the fixed commit.

Thanks again for the bug report and your patience.

@jonathannaguin
Copy link
Author

Hey @ben-manes, no problem, I am using a dummy value until this gets released.
Thanks a lot for your support.

@ben-manes
Copy link
Owner

Sorry for the long delay, this has been released.

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

No branches or pull requests

2 participants