hazelcast/hazelcast — pull request #3440 by jerrinot (2014-08-28 22:00:26+00:00)
Title: fixing #3162

When a ReplicatedMap proxy is obtained it's pre-populated from another member.
This is an asynchronous process.

If the other member is mutating the replicated map at the same time as the pre-population
is in progress then a same entry can be sent to the new member as two distinct events:
- once as a part of the initial load
- once as the result of the map mutation

Both events will have the same state of the vector clock.
I believe this issue caused the occasional test failures as it was evaluated as a conflict
by the vector clock logic. The conflict might result in new update events being generated as
part of the conflict resolution and this eventually confused the test.

The condition can be simulated by introducing delay in ReplicatedMapInitChunkOperation.

The fix is rather easy - if the incoming vector clock has the same state as a local entry then the update
is silently ignored.