[
https://issues.apache.org/jira/browse/CAMEL-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588948#comment-16588948
]
Philippe Bouteleux commented on CAMEL-12727:
--------------------------------------------
No definitive results yet from our full perf platform. However, from our CI
smaller stress test, after having integrated our own aggregation repository
bypassing the hack and therefore the copy, no more exception occurred for now.
Which sounds good.
Now, IMHO, re-introducing the ConcurrentHashMap is the proper and safer
solution. However, adding the lock within the hack only has less impacts on
performances. Q: is this hack really still useful ?
> 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
> Fix For: 2.23.0
>
> 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)
