[
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)
