[
https://issues.apache.org/jira/browse/CAMEL-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350317#comment-14350317
]
Serge Smertin commented on CAMEL-8438:
--------------------------------------
Final conclusion - optimistic locking for HazelcastAggregationRepository does
not work at all:
- test cases don't cover complex objects like hasmaps and multiple headers
- every time exchange is completed with predicate or with forced shutdown, new
property is being added by AggregateProcessor, so cache.remove(key, holder) is
always false. so that means, exchange would never be removed, as modified one
would have new property set. It might be a good idea to do compare-and-swap on
holder without properties. or creating different implementation of holder. or
extending a holder.
- HazelcastAggregationRepository is one of the few final classes within the
project, which makes me sad and incapable of extending it
> [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)
