Mule 3.9.0 - java.util.ConcurrentModificationException: null

Question

I am using Mule 3.9.0 CE

While doing load testing with multiple thread on Mule Flow, I got this exception: java.util.ConcurrentModificationException: null

All Mule flow and sub-flow Processing Strategies = default

java.util.ConcurrentModificationException: null
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442) ~[?:1.8.0_152]
at java.util.HashMap$EntryIterator.next(HashMap.java:1476) ~[?:1.8.0_152]
at java.util.HashMap$EntryIterator.next(HashMap.java:1474) ~[?:1.8.0_152]
at org.mule.module.http.internal.HttpMapParam.resolveMapObjObj(HttpMapParam.java:68) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.HttpMapParam.resolve(HttpMapParam.java:48) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.HttpMessageBuilder.resolveParams(HttpMessageBuilder.java:48) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.HttpResponseBuilder.build(HttpResponseBuilder.java:116) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.HttpMessageProcessorTemplate.doBuildResponse(HttpMessageProcessorTemplate.java:122) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.HttpMessageProcessorTemplate.buildResponse(HttpMessageProcessorTemplate.java:112) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.HttpMessageProcessorTemplate.sendResponseToClient(HttpMessageProcessorTemplate.java:86) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:79) ~[mule-core-3.9.0.jar:3.9.0]
at org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:36) ~[mule-core-3.9.0.jar:3.9.0]
at org.mule.execution.PhaseExecutionEngine$InternalPhaseExecutionEngine.process(PhaseExecutionEngine.java:114) ~[mule-core-3.9.0.jar:3.9.0]
at org.mule.execution.PhaseExecutionEngine.process(PhaseExecutionEngine.java:41) ~[mule-core-3.9.0.jar:3.9.0]
at org.mule.execution.MuleMessageProcessingManager.processMessage(MuleMessageProcessingManager.java:32) ~[mule-core-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.DefaultHttpListener$1.handleRequest(DefaultHttpListener.java:135) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.grizzly.GrizzlyRequestDispatcherFilter.handleRead(GrizzlyRequestDispatcherFilter.java:100) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) ~[grizzly-framework-2.3.33.jar:2.3.33]
at org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy.run0(ExecutorPerServerAddressIOStrategy.java:119) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy.access$100(ExecutorPerServerAddressIOStrategy.java:31) ~[mule-module-http-3.9.0.jar:3.9.0]
at org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy$WorkerThreadRunnable.run(ExecutorPerServerAddressIOStrategy.java:142) ~[mule-module-http-3.9.0.jar:3.9.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_152]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]

This behavior is not exist on Mule 3.4.1

All processing in my flow is "Sync." why these:

at org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:79) ~[mule-core-3.9.0.jar:3.9.0]
at org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:36) ~[mule-core-3.9.0.jar:3.9.0]

Could you post some of your flow XML? What do you mean by "sub-flow Processing Strategies = default"? Are you using private flows? In the case of using private flows, it is recommended to explicitly define the processingStrategy (synchronous or asynchronous). If the processing strategy is not specified explicitly, the synchronicity of the inflow event will be used to select one for the private flow. The events that are generated from one-way endpoints will be executed anychronously, even if the calling flow is expecting a response from the private flow. This could explain the async. — Attila, Mar 08 '18 at 10:18

Mule 3.9.0 - java.util.ConcurrentModificationException: null

0 Answers0