7:13 a.m.
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...
#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}" />
<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>
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)
7:29 a.m.
Looks good. I'm definitely in favour of a simpler config.
On 21 Sep 2012, at 13:13, Bela Ban <bban(a)redhat.com> 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...
#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}" />
<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>
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
7:35 a.m.
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9:06 a.m.
I like Bela's configuration. Maybe take it a step further and allow a
default backup configuration for all sites?
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: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Mircea 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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9:37 a.m.
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:
infinispan-dev-bounces@lists.jboss.org[mailto:infinispan-dev-bounces@lists.jboss.org] 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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4475
days inactive
4475
days old
infinispan-dev@lists.jboss.org
4 comments
4 participants
participants (4)
-
Bela Ban -
Erik Salter -
Manik Surtani -
Mircea Markus