Use ConcurrentHashMap in PersistentEntitiesResourceMappings instead of ConcurrentReferenceHashMap [DATAREST-1502]

[spring-projects-issues]

Mark Paluch opened DATAREST-1502 and commented

---

Affects: 3.2.6 (Moore SR6), 3.3 RC1 (Neumann)

Issue Links:

• DATAREST-1505 In case of low memory after GC all repository mappings are removed and 404 is returned
  ("is duplicated by")
• DATAREST-1518 All the repositories start to respond 404 after some period of time (10-12 hours)
  ("is duplicated by")
• DATAREST-1506 Accidental cache evictions in PersistentEntitiesResourceMappings
  ("is duplicated by")
• DATAREST-1262 PersistentEntitiesResourceMappings throws ConcurrentModificationException
  ("is duplicated by")
• DATAREST-1489 ConcurrentModificationException in PersistentEntitiesResourceMappings.getMappingFor(…)

Backported to: 3.2.7 (Moore SR7)

[spring-projects-issues]

Mark Paluch commented

The underlying cause is that PersistentEntitiesResourceMappings.exportsTopLevelResourceFor iterates over the cache. ConcurrentReferenceHashMap evicts both, keys and values. Since iteration over the value set does not trigger any lazy computation, exportsTopLevelResourceFor returns always false. We should switch to ConcurrentHashMap to avoid this effect and avoid re-computation of paths since repositories/entity types cannot be removed during runtime

[spring-projects-issues]

mle-enso commented

So good to hear this solution, Mark! This issue kept my team and me busy for the last 4 days since we've upgraded to Boot 2.2.6 and we were really racked with self-doubt due to the intermittent behavior of DATAREST-1489.
Glad you could solve this that fast. Keep up this excellent work!

[spring-projects-issues]

Édouard Hue commented

We stumbled on this issue too after upgrading from Spring Boot 2.2.4 to 2.2.6. We are rolling back waiting for SDR 3.2.7. Is there already a date for the release ?