camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Smertin (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CAMEL-8438) [Aggregation] [Optimistic Locking] [Hazelcast] Binary representation of same exchanges are different
Date Wed, 04 Mar 2015 20:12:38 GMT
Serge Smertin created CAMEL-8438:
------------------------------------

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

Mime
View raw message