Re: [infinispan-dev] [ISPN-78] Alternative interface for writing large objects
Am 15.04.11 16:54, schrieb Manik Surtani:
On 4 Apr 2011, at 11:01, Olaf Bergner wrote:
>> What we somehow need to avoid is chunks ending up in nodes that do not
>> have enough memory to store them, and that could complicate things.
> Definitely. What about replication, for instance? Does INFINISPAN use the replication
mechanism suggested by Dynamo, i.e. walking the constant hash ring in clockwise direction
until the desired number of replicas is reached (if I recall correctl)? I'm afraid
this might fail in our case.
Yes, this is how Infinispan's distribution works. Just for clarification, we refer
to this as distribution rather than replication.
On the other hand, when we speak of replication, we mean copies are repliciated to ALL
other nodes in the cluster. I.e., each node is a replica of its neighbour, and all nodes
are treated equal. Replication, as such, has no need for a consistent hash wheel.
Why do you feel this may fail?
This fear rested on the assumption that no two
chunks may be stored on
the same node. I has code in place to enforce this, yet it didn't take
distribution into account.
Meanwhile, following Sanne's suggestion's, I removed a great deal of my
earlier code's complexity and rely on INFINISPAN's constant hashing
algorithm to evenly distribute chunks across the cluster.
> Plus, I fear rehashing would have to be aware of wheter it is
dealing with relocating a large object chunk or a "regular" value.
See
above: if a node leaves the cluster rehashing might relocate large
object's A 's chunk to a node that already has another chunk belonging
to A stored. Again, this argument is obsolete by now.
Cheers,
Olaf
Again, why is this the case?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev