My original message bounced. In other words, if in practice you want N
copies of something to exist, you can either select N nodes from the
same hash wheel, or create N hash wheels. In this case you'd create at
least two.
On Wed, Sep 22, 2010 at 7:37 AM, Elias Ross <genericelias(a)gmail.com> wrote:
What about multiple hash wheels? One would exclude those nodes
co-located, another would include all nodes.
-----Original Message-----
From: Vladimir Blagojevic <vblagoje(a)redhat.com>
Sender: infinispan-dev-bounces(a)lists.jboss.org
Date: Wed, 22 Sep 2010 09:44:54
To: infinispan -Dev List<infinispan-dev(a)lists.jboss.org>
Reply-To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
Subject: Re: [infinispan-dev] Collocated nodes
The current function that places nodes on a hash wheel is deterministic in case of node
joins and crashes/leaves. Even after a node leaves/crashes all surviving nodes in view
V' are going be positioned to same hash wheel position as in view V. In another words,
all surviving nodes in V' are deterministically placed on the same hash wheel
positions absolutely and relatively to each other as they were in view V. The case for
join is superfluous to my argument.
I am still learning about this topic but it seems that hash wheel node placing property
defined above is necessary for everything to work properly. If so, I find it very hard to
devise an algorithm that places nodes on hash wheel based on distance. As soon as one node
crashes/leaves positioning surviving nodes in V' to same positions as they were in
view V seems impossible since in distance based positioning we need to place nodes in
relation to neighbouring nodes.