Cool, I'll implement Bela's suggestion for the next release:
https://issues.jboss.org/browse/ISPN-2332
On 21 Sep 2012, at 17:06, Erik Salter wrote:
> I like Bela’s configuration. Maybe take it a step further and allow a
> default backup configuration for all sites?
the backup configuration is now inherited from the default site even now, or
are you referring to something else?
>
> FWIW, here’s my config. I get warnings about looping back to the site, but
> it seems to work.
>
> <global>
>
> <sites local="${net.beaumaris.site.local:site1}">
> <site name="${net.beaumaris.site.site01:site1}"/>
> <site name="${net.beaumaris.site.site02:site2}"/>
> <site name="${net.beaumaris.site.site03:site3}"/>
> </sites>
> …
> <default>
>
> <sites>
> <backups>
> <backup site="${net.beaumaris.site.site01:site1}" strategy="ASYNC"/>
> <backup site="${net.beaumaris.site.site02:site2}" strategy="ASYNC"/>
> <backup site="${net.beaumaris.site.site03:site3}" strategy="ASYNC"/>
> </backups>
> </sites>
>
> Erik
>
> From:
> [email protected][mailto:[email protected]]
> On Behalf OfMircea Markus
> Sent: Friday, September 21, 2012 8:36 AM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Cross-site clustering
>
>
> On 21 Sep 2012, at 15:13, Bela Ban wrote:
>
>
> Hi Mircea,
>
> I'm in the process of setting up the Infinispan GUI demo across 3 data
> centers, and I ran into an issue with the Infinispan config file. Not
> really a bug, but something that could be improved.
>
> Currently, the Infinispan config (let's call it infinispan.xml) defines
> the sites and their backup sites and refers to the local JGroups cluster
> config file (jgroups.xml). The latter has a RELAY2 protocol at the top
> of its stack which points to the relay configuration (relay2.xml), which
> defines the sites and how they connect to each other. Finally, there's a
> jgroups-relay2.xml file (referred to from relay2.xml) which defines the
> global bridge, connecting all 3 sites.
>
> OK, so that 4 config files and I don't see how to reduce them.
> However... currently infinispan.xml is *site-specific*, ie. we need 1
> infinispan.xml for LON, 1 for SFO and 1 for NYC.
>
> The 3 JGroups config files (jgroups.xml, relay2.xml and
> relay2-bridge.xml) are *not* site-specific, ie. they can be used in any
> site, provided that we set a few system properties, such as
> cluster-specific mcast address and port, and site name (relay2.xml).
>
> I believe cross-site clustering would benefit from making infinispan.xml
> symmetric as well, that is, we could use it in any site.
>
> To do this, I suggest the following:
>
> #1 Sites config:
> <sites local="LON">
> <site name="SFO"/>
> <site name="NYC"/>
> <site name="LON"/>
> </sites>
>
>
> Nothing needs to be changed here, except to parameterize local: <sites
> local="${SITE:LON}"...>. A node in a given site can then be started
> using -DSITE=LON. This could also be used for relay2.xml.
>
> - Question-1: why do we need to list the sites above ? We're not
> defining any config for those sites, so I don't see why this is needed…
> yes, defining these sites is not required. The only thing that's needed is
> <sites local="LON">
>
>
> #2 Backups config:
> <namedCache name="users">
> <sites>
> <backups>
> <backup site="NYC" backupFailurePolicy="WARN"
> strategy="SYNC" timeout="12000"/>
> <backup site="SFO" backupFailurePolicy="IGNORE"
> strategy="ASYNC"/>
> </backups>
> </sites>
> </namedCache>
>
>
> This is *asymmetric*. IMO, a better config would be:
>
> <global>
> <sites>
> <localSite="${site:LON}" backupSites="${backup-sites:SFO,NYC}" />
> This would require configuring "localSite" for all caches in the system.
> Unless added to the default cache and forbid an override. I'd prefer to keep
> it in the global, but don't really have a strong feeling about it.
> <backups>
> <backup site="NYC" backupFailurePolicy="WARN"
> strategy="SYNC" timeout="12000"/>
> <backup site="SFO" backupFailurePolicy="IGNORE"
> strategy="ASYNC"/>
> <backup site="LON" backupFailurePolicy="IGNORE"
> strategy="ASYNC"/>
> </backups>
> </sites>
> </global>
>
> For me the above seems harder to read than the one currently in use, but otoh
> simplifying the config would be something nice.
> What do other think? Erik?
>
>
>
> Here, we define global backup strategies and the local site. Both of
> them can be parameterized, e.g. we start up nodes in
> - LON: -Dsite=LON -DbackupSites="SFO,NYC"
> - SFO: -Dsite=SFO -DbackupSites=NYC
> - NYC: -Dsite=NYC -DbackupSites= // no backups
>
>
> This would allow us to have only 1 infinispan.xml, regardless of the
> site in which it is used.
>
> Of course, since backup strageties are globally defined, if people
> wanted different backup strategies per site (or per named cache), they
> could still copy infinispan.xml and modify it...
>
> WDYT ?
>
>
>
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
