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)
