Ok, these rehash designs are flawed. While they work in concept, they
could lock up a cluster for periods of time while a rehash is in
progress, since every node may provide some state to every other node,
and while state is being streamed, a recipient would need to queue
incoming transactions to be applied on top of any state applied.
While this will work very well if just one node receives state at at
time, it won't work if (theoretically) every node receives some state
(for example if a node leaves).
I have an alternate approach (sketched out in a notebook here) which
will mean some redesign to the core dist code, I will publish these on
the wiki when I get back from vacation.
In the meanwhile though, it means no Beta1 today (boo!) but I will
push out an Alpha5 (yaayy!) since there are a lot of other changes and
improvements which I want to make public.
Watch this space.
Cheers
Manik
On 8 Jun 2009, at 15:34, Manik Surtani wrote:
Ok, so here is where I have jotted down designs for rehashing in
DIST.
http://www.jboss.org/community/wiki/DIST-distributedcachemode#Rehashing
Please have a look and comment accordingly. Some points:
1. Heterogenous nodes are not supported at this time. I expect to
add support for this later.
2. Actual state is transferred using RPC calls. A more efficient
streaming mechanism will come in later.
3. Each view change will result in a rehash event. Combining view
changes to a single rehash is something we would consider for later.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org