[jira] [Created] (CAMEL-14136) ConcurrentModificationException when using recipientList with Strings

["Christian Mohr (Jira)" <ji...@apache.org>]

Christian Mohr created CAMEL-14136:
--------------------------------------

             Summary: ConcurrentModificationException when using recipientList with Strings
                 Key: CAMEL-14136
                 URL: https://issues.apache.org/jira/browse/CAMEL-14136
             Project: Camel
          Issue Type: Bug
          Components: camel-core
    Affects Versions: 3.0.0.RC3
         Environment: Java 11, Camel 3.0.0RC3
            Reporter: Christian Mohr


I already asked this on the mailing list:

I encountered a ConcurrentModificationException in Camel: 
{code:java}
java.util.ConcurrentModificationException: null 
                at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134) 
                at org.apache.camel.util.Scanner.cachePattern(Scanner.java:305) 
                at org.apache.camel.util.Scanner.<init>(Scanner.java:82) 
                at org.apache.camel.support.ObjectHelper.lambda$createIterable$3(ObjectHelper.java:593) 
                at org.apache.camel.support.ObjectHelper$$Lambda$1118.0000000000000000.iterator(Unknown Source) 
                at org.apache.camel.support.ObjectHelper.createIterator(ObjectHelper.java:435) 
                at org.apache.camel.support.ObjectHelper.createIterator(ObjectHelper.java:412) 
                at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:137) 
                at org.apache.camel.processor.RecipientList.process(RecipientList.java:125) 
                at org.apache.camel.processor.Pipeline.doProcess(Pipeline.java:103) 
                at org.apache.camel.processor.Pipeline.lambda$null$2(Pipeline.java:104) 
                at org.apache.camel.processor.Pipeline$$Lambda$1096.0000000000000000.run(Unknown Source) 
                at org.apache.camel.impl.engine.DefaultReactiveExecutor$3.run(DefaultReactiveExecutor.java:116) 
                at org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:185) 
                at org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:67) 
                at org.apache.camel.spi.ReactiveExecutor.schedule(ReactiveExecutor.java:32) 
                at org.apache.camel.processor.MulticastProcessor.lambda$schedule$1(MulticastProcessor.java:249) 
                at org.apache.camel.processor.MulticastProcessor$$Lambda$1099.0000000000000000.run(Unknown Source) 
                at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) 
                at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) 
                at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) 
                at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
                at java.base/java.lang.Thread.run(Thread.java:831) {code}
My simplified route is as follows. The input is a list of objects, these are split, and based on the object the recipientList is different. When there are two recipients in the String provided by „getRecipients", the named exception is thrown. Sadly not consistently. 
{code:java}
  from("seda:input") 
      .split(method(TestClass.class, "split"), AggregationStrategies.groupedBody()) 
        .parallelProcessing() 
        .recipientList(method(TestClass.class, "getRecipients")) 
          .parallelProcessing() {code}
It looks like the Scanner uses an internal map of compiled Patterns, but this map (LinkedHashMap) is not threadsafe. 

 

Response from Claus Ibsen:

Yeah its a bug in Camel 3, you are surely welcome to log a JIRA ticket 
and work on a patch. 
I can see we (gnodet) introduced a custom fast scanner implementation, 
but its not thread safe. 

We could add synchronization block to that compute if absent. And for 
those constant patterns WHITE_SPACE, FIND_ANY etc we can make them 
static 
as java.util.Pattern is thread-safe and create them once in a class 
static block.

 

I did that and will post a PR-Request to the github project shortly, when the ticket number is known.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)