[
https://issues.apache.org/jira/browse/CAMEL-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354505#comment-14354505
]
Claus Ibsen commented on CAMEL-8438:
------------------------------------
You are welcome to work on a patch to not make it final, but also to try to
fix/improve this
> [Aggregation] [Optimistic Locking] [Hazelcast] Binary representation of same
> exchanges are different
> ----------------------------------------------------------------------------------------------------
>
> Key: CAMEL-8438
> URL: https://issues.apache.org/jira/browse/CAMEL-8438
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
> Affects Versions: 2.14.0
> Reporter: Serge Smertin
>
> After some low-level debugging i've figured out that it's not possible to use
> optimistic locking for HazelcastAggregationRepository, as marshalled
> exchanges have different representation on binary level and some of
> distributed atomic update operations by design rely on it. So it might be
> also relevant for aggregation repositories with optimistic locking for other
> backends. Problem is that inHeaders of DefaultExchangeHolder is marshalled as
> LinkedHashMap, which may change physical order of entries, still giving same
> hash code after unmarshalling.
> As workaround - create special class for holding all aggregation properties
> and not to use more than one header.
> How to reproduce:
> create a unit test with embedded hazelcast instance, hazecast agg. repository
> and let newExchange's have more than one header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
