Manik Surtani wrote:
On 5 Aug 2010, at 08:29, Bela Ban wrote:
> Yes, I know #1 sucks, but until we've implemented the more advanced
> solutions (e.g. RELAY in JGroups, data center replication in
> Infinispan), this seems to me a workable solution that could be
> implemented in a short time.
Would this be usable though? The thing with #1 is that you will force
all traffic over a WAN link.
Yes. I know of several customers who have set up and run clusters over
WAN links. Most of them use TCP, but I know of 2 customers who run IP
multicasting across data centers over OC-48 fiber.
Until a few years ago, I've always recommened against this (I mean
clusters across WANs), but it seems it works for folks, and so I'll be
working on making this a better choice. Some of the things that will
help are relaying traffic between separate islands (RELAY), daisy
chaining and optimizing traffic across the WAN link etc.
So even if you have 4 owners, 2 in each DC, the "local"
replication,
there will be no way to write to the local backup synchronously and
the remote backups asynchronously. I.e., either all comms are sync or
all comms are async.
Yes, correct. However, this is something which could be implemented in
Infinispan, ie. configure a mode (DIST_SYNC_ASYNC ?) where the primary
owner of a key is updated synchronously and the other(s) asynchronously.
Apart from data center replication, this might even be a nice feature to
have in Infinispan proper ?
Maybe this is something we can add in Infinispan. I.e., with node
hints (
https://jira.jboss.org/browse/ISPN-180) (*) we could detect
which recipients are local and which are remote, and accordingly split
the RPC into 2: a sync local RPC and an async remote RPC.
+1
(*) Node hinting isn't strictly necessary; the naming convention
you
mentioned earlier would work in this regard as well, although I think
these hints is probably a better universal solution since we need this
for other things anyway.
+1 again
--
Bela Ban
Lead JGroups / Clustering Team
JBoss