You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Christian Mohr (Jira)" <ji...@apache.org> on 2019/11/04 15:16:00 UTC

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

     [ https://issues.apache.org/jira/browse/CAMEL-14136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Mohr updated CAMEL-14136:
-----------------------------------
    Patch Info: Patch Available

> 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
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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)