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] [Commented] (CAMEL-8438) [Aggregation] [Optimistic Locking] [Hazelcast] Binary representation of same exchanges are different
Date Fri, 06 Mar 2015 13:11:39 GMT

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

Mime
View raw message