camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-8438) [Aggregation] [Optimistic Locking] [Hazelcast] Binary representation of same exchanges are different
Date Thu, 09 Jul 2015 10:52:04 GMT

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

Claus Ibsen updated CAMEL-8438:
-------------------------------
    Fix Version/s: Future

> [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)

Mime
View raw message