-
Notifications
You must be signed in to change notification settings - Fork 682
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
Repository information cache map keeps growing until out of memory #3252
Comments
Looks like a regression. It also seems, that we do not benefit from proper caching as the cache keys do not yield many cache hits. |
Two things contribute to cause this problem:
|
We now use a refined strategy to cache RepositoryInformation and RepositoryComposition. Previously, RepositoryComposition wasn't cached at all and store modules that e.g. contributed a Querydsl (or a different) fragment based on the interface declaration returned a new RepositoryComposition (and thus a different hashCode) each time RepositoryInformation was obtained leading to memory leaks caused by HashMap caching. We now use Fragment's hashCode for the cache key resulting in RepositoryComposition being created only once for a given repository interface and input-fragments arrangement. Closes #3252
That's fixed now. A new snapshot build of |
We now use a refined strategy to cache RepositoryInformation and RepositoryComposition. Previously, RepositoryComposition wasn't cached at all and store modules that e.g. contributed a Querydsl (or a different) fragment based on the interface declaration returned a new RepositoryComposition (and thus a different hashCode) each time RepositoryInformation was obtained leading to memory leaks caused by HashMap caching. We now use Fragment's hashCode for the cache key resulting in RepositoryComposition being created only once for a given repository interface and input-fragments arrangement. Closes #3252
I've just tested it against |
Hi,
it looks like there is a bug in
RepositoryFactorySupport
in combination withQuerydslPredicateExecutor
causing the repository information cache map to grow indefinitely, which eventually leads to OOM:Heap usage in version 3.4.3 (same for 3.4.x):

Heap usage in version 3.3.9:

Steps to reproduce and observed behaviour
I'm attaching a sample application below which is based on Spring Data REST, Spring Data JPA and Querydsl:
spring-repository-cache-map-issue.zip
repositoryInformationCache
)cacheKey
is always unique because itscompositionHash
is calculated fromQuerydslJpaPredicateExecutor
which doesn't overridehashCode
method.The thing is, it behaves the same in version 3.3.9 as well. But there was:
(changed in #3067 - b21b2e8)
so if I understand correctly, the values were always garbage collected because of the
WEAK
reference type.The text was updated successfully, but these errors were encountered: