[jira] [Resolved] (CAMEL-8438) [Aggregation] [Optimistic Locking] [Hazelcast] Binary representation of same exchanges are different

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-8438.
--------------------------------
    Resolution: Abandoned

> [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
>            Priority: Major
>             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
(v8.20.10#820010)