ORSet's merge use VectorClock

[netcomm]

i noticed akka-Data-Replication also use VectorClock(source from Akka), i have some question:
use ordered UniqueAddress for compare in Akka's VectorClock maybe it is ok, because the akka memberships status maintained by one 'leader' node,and leader is in the first place in UniqueAddress of nodes ring (my understanding is correct?)
but for ORSet's merge, it use Set's VectorClock to compare element's 'birth dot', in the 'mergeDisjointKeys' function 'if (vclock > dots || vclock == dots)'
this '>' compare also use ordered UniqueAddress, is it necessary? or just maybe compare 'vclock.versions.get(node)' vs dots?
if i miss something, please correct me, thanks!

[patriknw]

The ordering by unique address has nothing to do with leader. It was introduced in an optimization effort in these two commits:
akka/akka@1adfcb8#diff-4
akka/akka@a487edf#diff-0

I'm sure a lot of things can be optimized in the ORSet, including using a tailored version vector and birth dot implementation. That should be done in a systematic way, including using JMH benchmarking to find the best solution.

So far I have not had the time to do so, and so far I have preferred to use existing (tested) Akka VectorClock and algorithms close to the riak_dt_orswot, which was the source of inspiration.

Thanks for the question. I'm leaving the issue open, as an reminder for future optimization work.

[netcomm]

thanks for the detailed explanation, i will read these issues.To be honest, Akka has more and more complex. the Akka's User DOC is very excellent, but there are lack of Akka inside implements analysis.
search in google, can find very few, Jonas Bonér's write one about akka Cluster Implementation Notes (https://gist.github.com/jboner/7692270), but it is still more top level.
maybe can have some changes, thanks!