Thanks Ray, yes, each site has the other 2as backup sites. The current assumption though is for xsite replication to only be unidirectional, e.g. LON --> SFO/NYC, or if it is bidirectional, for the data that's concurrently accessed to be disjoint.
This setup allows LON to be the active site and SFO/NYC to be the backup sites. One could imagine a follow-the-sun implementation where LON becomes inactive and NYC becomes active when it is EOB in LON. Later, SFO becomes active, then LON again and so on. In IRAC [1], we'll handle the problem of concurrent updates from different sites to the same data set. [1] https://community.jboss.org/wiki/RAC On 12/15/12 4:41 AM, Ray Tsang wrote: > Great stuff Bela! > > Btw, is xsite replication bidirectional? LON has SFO as backup, and > SFO also has LON as backup. > > On Fri, Dec 14, 2012 at 8:01 PM, Sanne Grinovero <[email protected] > <mailto:[email protected]>> wrote: > > That was very very nice to see. > > Assuming you also asked for feedback to improve this as a talk: > > 1# you stress several times that reads are going to be local, so very > fast. I think you meant "local to the site" ? as some ~33% of entries > will need to be fetched from peers on the same site. > > 2# you aren't actually running this on multiple sites are you? When > pointing out the different IP addresses you say something about > needing them to be different, but I didn't understand if you needed > them different because they are in different places, or to separate > otherwise local machines to have them appear as in different places. > > 3# Since get operations are always local (site), they are as you say > not meaningful for the benchmark; now since put operations are also > not meaningful as it's async .. what is the benchmark measuring? > > 4# There seems to be some degree of redundancy when explaining > LON/SFO/NYC setting as the local site vs the backup sites. Wouldn't it > make more sense to be able to configure all backup sites the same and > have it automatically ignore the "self" element as a backup site? So > your script would only need to specify what the local site is. If that > makes any sense it would even be nice to extend this to the IP > addresses being defined in the zones area, so that they are applied > both to the JGroups configuration for the local cluster and to the > bridge configuration. > > 5# I was initially surprised to see x-site configuration as part of a > cache configuration; I understand the reasons for options like > "strategy" which one might want to specify differently on each cache, > but what about "take offline" ? that sounds more something which > should be globally managed at the channel level - not sure if in > JGroups directly but if it's to be handled in Infinispan I would > expect to have all caches use the same policy, consistent with FD. > Also it doesn't looks like you have much of a choice in to which sites > you want to replicate, as relay is setup at the jgroups level so > affecting all caches: is relay going to be ignored by caches having no > x-site enabled? And is it going to be relayed only to one site if the > Infinispan configuration lists a single site? > Not sure if this makes any sense, I just found it contrasting with my > naive expectations of how such a configuration would look like. > > thanks a lot, I hope this is proof enough that your video was > pretty catchy :) > Cheers, > Sanne > > On 14 December 2012 11:47, Radoslav Husar <[email protected] > <mailto:[email protected]>> wrote: > > Thanks Bela, I enjoyed the demo! > > > > I suggest adding some sort of visualization (maybe just a few > diagrams > > within the demo) of what is actually happening with the data > would help > > understanding for users who are just starting with xsite. > > > > Rado > > > > On 14/12/12 12:09, Bela Ban wrote: > >> FYI, > >> > >> I've uploaded a 10-minute video [1] to YouTube showing how I > setup and > >> run a perf test for Infinispan xsite replication [2]. The test > >> (including all configuration) is available at [3]. This was run > with a > >> snapshot of Infinispan (roughly 5.2.0.Beta6) and JGroups > 3.3.0.Alpha1. > >> Enjoy ! > >> > >> [1] http://www.youtube.com/watch?v=owOs430vLZo > >> [2] > https://docs.jboss.org/author/display/ISPN/Cross+site+replication > >> [3] https://github.com/belaban/IspnPerfTest > >> > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
