[ https://issues.apache.org/jira/browse/CAMEL-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16579480#comment-16579480 ]
Philippe Bouteleux commented on CAMEL-12727: -------------------------------------------- You are certainly right as the lines of code where the exception occurs depends on tests on optimisticLocking and aggregationRepository being in-memory (AggregateProcessor.java line 398 in 2.20.1): // hack to support legacy AggregationStrategy's that modify and return the oldExchange, these will not // working when using an identify based approach for optimistic locking like the MemoryAggregationRepository. if (optimisticLocking && aggregationRepository instanceof MemoryAggregationRepository) { oldExchange = originalExchange.copy(); } Please note that we did not choose to follow the repository pattern to save each individual message to disk but we chose to directly save them in the aggregation strategy class we provided. Actually, the default MemoryAggregationRepository is of no use in our use case and shall may be replaced by our own 'null repository' to not put pressure on the garbage collector for nothing. This may also workaround the issue as the conditional test would be false and the exchange would not be copied and would not crash. > java.util.ConcurrentModificationException at > org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) > in 2.20.1 > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CAMEL-12727 > URL: https://issues.apache.org/jira/browse/CAMEL-12727 > Project: Camel > Issue Type: Bug > Components: camel-core > Affects Versions: 2.20.0 > Environment: Camel 2.20.1. > The exception occurs within a aggregation processor using a custom > aggregation strategy and optimistic locking. > Reporter: Philippe Bouteleux > Priority: Major > Attachments: dih-error.queue_2 (1).txt > > > A concurrent access exception occurs during our load tests while consuming > messages from a rabbitmq queue. > The call stack embedded below shows that the issue is related to an > "optimization" which was introduced in > https://issues.apache.org/jira/browse/CAMEL-11330 to replace a > ConcurrentHashMap with a regular one from version 2.19.5 to 2.20.0 onward. > The faulty code is still present in latest 2.22.0. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)