ConcurrentModificationException in DispatcherServlet with asynchronous ApplicationEventMulticaster [SPR-17442]

[spring-projects-issues]

Jared Wiltshire opened SPR-17442 and commented

We are occasionally seeing a ConcurrentModificationException thrown from DispatcherServlet.initHandlerMappings(ApplicationContext context) due to the sorting of the handler mappings from two different threads (DispatcherServlet line 590 in 5.0.10).

I traced the cause of this back to our use of SimpleApplicationEventMulticaster with an asynchronous task executor.

What is happening is that FrameworkServlet.initWebApplicationContext() calls configureAndRefreshWebApplicationContext(cwac) which fires off a ContextRefreshedEvent. This results in onApplicationEvent(ContextRefreshedEvent event) being called from an executor thread which then calls onRefresh(event.getApplicationContext()). Further down in initWebApplicationContext() (FrameworkServlet line 557) it checks the boolean refreshEventReceived and calls onRefresh(wac) again from the main thread as there is no synchronization.

 

---

Affects: 5.0.10

Issue Links:

• StandardEvaluationContext does not support concurrent variable access [SPR-17448] #21980 StandardEvaluationContext does not support concurrent variable access

Backported to: 5.0.11

[spring-projects-issues]

Juergen Hoeller commented

I've revised this towards an AtomicBoolean onRefreshTriggered which is being explicitly checked in both places now. Whoever gets there first takes the token and is responsible for the actual onRefresh call. In particular, if the ContextRefreshedEvent happens to come after the initWebApplicationContext() phase (as in your scenario), it will simply be ignored now.

[spring-projects-issues]

Juergen Hoeller commented

Turns out it's not quite as straightforward since we support DispatcherServlet re-refreshs, as rarely as that may be used in practice...

[spring-projects-issues]

Juergen Hoeller commented

On review, full synchronization of the onRefresh callback seems to be necessary for all scenarios to work correctly, in combination with the existing refreshEventReceived flag which skips an unnecessary re-refresh on initial setup in a regular single-threaded bootstrap scenario.

[spring-projects-issues]

Jared Wiltshire commented

Thanks Juergen Hoeller for looking at this. Fix looks good.