Hi,
it looks like there is a bug in RepositoryFactorySupport in combination with QuerydslPredicateExecutor 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
- Each HTTP resource request (GET /someItems) will produce a unique entry in repository information cache (
repositoryInformationCache)
- So the number of entries in the map will be equal to number of executed HTTP requests
- The
cacheKey is always unique because its compositionHash is calculated from QuerydslJpaPredicateExecutor which doesn't override hashCode method.

The thing is, it behaves the same in version 3.3.9 as well. But there was:
new ConcurrentReferenceHashMap<>(16, ReferenceType.WEAK)
(changed in #3067 - b21b2e8)
so if I understand correctly, the values were always garbage collected because of the WEAK reference type.
Hi,
it looks like there is a bug in
RepositoryFactorySupportin combination withQuerydslPredicateExecutorcausing 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)cacheKeyis always unique because itscompositionHashis calculated fromQuerydslJpaPredicateExecutorwhich doesn't overridehashCodemethod.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
WEAKreference type.