camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-8438) [Aggregation] [Optimistic Locking] [Hazelcast] Binary representation of same exchanges are different
Date Tue, 10 Mar 2015 08:06:39 GMT


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:
>             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

View raw message