ConcurrentModificationException in very specific scenarios when indexing multiple entities with addOrUpdate which contains @IndexEmbedded dependencies
Description
Activity
Show:
Fixed
Details
Details
Assignee

Reporter

Sprint
None
Fix versions
Priority
Created March 6, 2020 at 7:59 PM
Updated September 25, 2023 at 2:48 PM
Resolved March 9, 2020 at 9:38 AM
In some cases the SearchIndexingPlan generate a ConcurrentModificiationException if an embedded entities is not listed in the addOrUpdate or on specific order (if only the last entity is concern this case)
Explanation from @yrodiere :
The problem is probably in
org.hibernate.search.mapper.pojo.work.impl.PojoIndexingPlanImpl#process
, in this loop:The call to
resolveDirty
will trigger a loop onindexingPlansPerId
that executes an operation of each element of that map.The problem is, this operation might trigger the addition of an element to the map
indexedTypeDelegates
(throughorg.hibernate.search.mapper.pojo.work.impl.PojoIndexingPlanImpl#getOrCreateIndexedDelegateForContainedUpdate
), or to the mapindexingPlansPerId
(throughorg.hibernate.search.mapper.pojo.work.impl.PojoIndexedTypeIndexingPlan#getPlan
), when we discover a type/entity that wasn’t present in the map initially.The concurrent modification is not a problem per se, because we don’t need to call
resolveDirty
on newly added elements. However, it’s a problem because the iterator will detect the concurrent modification and throw an exception.see https://discourse.hibernate.org/t/searchindexingplan-exception-when-using-addorupdate-in-different-order/3846