[
https://issues.apache.org/jira/browse/CAMEL-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620322#comment-14620322
]
Claus Ibsen commented on CAMEL-8438:
------------------------------------
I made the class able to extend in Camel 2.16 onwards.
> [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: Improvement
> Components: camel-hazelcast
> Affects Versions: 2.14.0
> Reporter: Serge Smertin
> Fix For: Future
>
>
> 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)
