ConcurrentModificationException when doing a merge on AbstractEnvironment [SPR-13213]

[spring-projects-issues]

Stephen Liang opened SPR-13213 and commented

I seem to get an occasional ConcurrentModificationException when doing a merge on various different threads. Perhaps merge() needs to be synchronized?

Caused by: java.util.ConcurrentModificationException
        at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373)
        at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384)
        at java.util.AbstractCollection.toArray(AbstractCollection.java:171)
        at org.springframework.util.StringUtils.toStringArray(StringUtils.java:816)
        at org.springframework.core.env.AbstractEnvironment.getDefaultProfiles(AbstractEnvironment.java:268)
        at org.springframework.core.env.AbstractEnvironment.merge(AbstractEnvironment.java:437)
        at org.springframework.context.support.AbstractApplicationContext.setParent(AbstractApplicationContext.java:402)
        at org.springframework.context.support.GenericApplicationContext.setParent(GenericApplicationContext.java:148)
        at org.springframework.webflow.engine.builder.model.FlowModelFlowBuilder.createFlowApplicationContext(FlowModelFlowBuilder.java:336)
        at org.springframework.webflow.engine.builder.model.FlowModelFlowBuilder.initLocalFlowContext(FlowModelFlowBuilder.java:302)
        at org.springframework.webflow.engine.builder.model.FlowModelFlowBuilder.doInit(FlowModelFlowBuilder.java:147)
        at org.springframework.webflow.engine.builder.support.AbstractFlowBuilder.init(AbstractFlowBuilder.java:46)
        at org.springframework.webflow.engine.builder.FlowAssembler.assembleFlow(FlowAssembler.java:90)
        at org.springframework.webflow.engine.builder.DefaultFlowHolder.assembleFlow(DefaultFlowHolder.java:109)
        at org.springframework.webflow.engine.builder.DefaultFlowHolder.getFlowDefinition(DefaultFlowHolder.java:84)
        at org.springframework.webflow.definition.registry.FlowDefinitionRegistryImpl.getFlowDefinition(FlowDefinitionRegistryImpl.java:61)
        at org.springframework.webflow.executor.FlowExecutorImpl.launchExecution(FlowExecutorImpl.java:138)
        at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:193)
        at org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:174)
        at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953)
        ... 227 more

---

Affects: 3.2.8

Issue Links:

• Concurrent registration/iteration in PropertySourcesPropertyResolver [SPR-12428] #17034 Concurrent registration/iteration in PropertySourcesPropertyResolver
• Consistent logging in Environment and PropertySource implementations [SPR-15825] #20380 Consistent logging in Environment and PropertySource implementations

Referenced from: commits d2447ce, e393c7b, af5f4e6

Backported to: 4.1.8, 3.2.15

[spring-projects-issues]

Juergen Hoeller commented

It looks like this may be caused by AbstractEnvironment's lazy resolution of the "spring.profiles.default" property... since for that reason, a call to doGetActiveProfiles may actually lead to a manipulation of the activeProfiles Set, which may in turn break a concurrent attempt to turn it into a String array in getDefaultProfiles. We'll make this more defensive for 4.2.2, backporting the fix to 4.1.8 if it is straightforward enough.

Juergen