9:04 a.m.
Hi all,
right on the heels of my previous e-mail related to declarative
configuration of XSite in Infinispan, I also would like to tackle the
issue of how we are going to translate it to the configuration dialect
in AS7/EAP/JDG.
Here's my rough concept:
add the local site name to the <cache-container /> element
<cache-container name="maximal" aliases="alias1 alias2"
default-cache="local" eviction-executor="infinispan-eviction"
jndi-name="java:global/infinispan/maximal"
listener-executor="infinispan-listener"
replication-queue-executor="infinispan-repl-queue"
module="org.infinispan"
local-site="LON">
add the backups element as a child of the cache:
<local-cache name="local">
<backups>
<backup site="NYC" failure-policy="WARN"
strategy="SYNC"
timeout="12000" enabled="true"/>
<backup site="SFO" failure-policy="IGNORE"
strategy="ASYNC"
enabled="true"/>
<backup site="LON" strategy="SYNC"
enabled="false"/>
</backups>
<backup-for remote-cache="remoteCache" remote-site="NYC"
/>
</local-cache>
Since the JGroups config already allows multiple stacks, I suggest
adding the relay element as a child of the <stack /> element allowing it
to reference other stacks:
<stack name="bridge">
<transport type="TCP" socket-binding="jgroups-bridge-tcp"
/>
</stack>
<stack name="xsite">
<transport type="TCP" socket-binding="jgroups-tcp" />
<protocol ... />
<relay type="relay.RELAY2">
<site name="LON" id="0">
<bridges>
<bridge name="global" stack="bridge" />
</bridges>
</site>
<site name="NYC" id="1">
<bridges>
<bridge name="global" stack="bridge" />
</bridges>
</site>
<site name="SFO" id="2">
<bridges>
<bridge name="global" stack="bridge"/>
</bridges>
</site>
</relay>
</stack>
Comments ?
Tristan
10:01 a.m.
On 10/18/12 4:04 PM, Tristan Tarrant wrote:
Hi all,
right on the heels of my previous e-mail related to declarative
configuration of XSite in Infinispan, I also would like to tackle the
issue of how we are going to translate it to the configuration dialect
in AS7/EAP/JDG.
Here's my rough concept:
add the local site name to the <cache-container /> element
<cache-container name="maximal" aliases="alias1 alias2"
default-cache="local" eviction-executor="infinispan-eviction"
jndi-name="java:global/infinispan/maximal"
listener-executor="infinispan-listener"
replication-queue-executor="infinispan-repl-queue"
module="org.infinispan"
local-site="LON">
+1 in general. However, I'm wondering if we could take into account
(Infinispan-only) properties siteId, rackId and machineId in the
<transport> element of Infinispan ? AFAIK these are currently not
configurable at the AS level, but once we add them, we'll have site (in
cache-container) and siteId (in transport).
It would be good if siteId and site could reside in the same XML element
and if we could name them the same. So perhaps change local-site to
siteId ? Or change siteId to site ?
Another thing we need to do is to use consistent naming; either adopt
the Java method naming standard (siteId)or the C-style (site-id).
add the backups element as a child of the cache:
<local-cache name="local">
<backups>
<backup site="NYC" failure-policy="WARN"
strategy="SYNC"
timeout="12000" enabled="true"/>
<backup site="SFO" failure-policy="IGNORE"
strategy="ASYNC"
enabled="true"/>
<backup site="LON" strategy="SYNC"
enabled="false"/>
</backups>
<backup-for remote-cache="remoteCache" remote-site="NYC"
/>
</local-cache>
I assume we'll still be able to define backups in the <default> section,
and can be overriden for individual caches, right ? I'd hate to have to
configure them for each cache individually...
What's the 'enabled' attribute for ? Online / offline ?
Furthermore, a big +1000 to *remove* the <backup-for> element, which I
think isn't needed (and I've said this before) ...
Since the JGroups config already allows multiple stacks, I suggest
adding the relay element as a child of the <stack /> element allowing it
to reference other stacks:
<stack name="bridge">
<transport type="TCP" socket-binding="jgroups-bridge-tcp"
/>
</stack>
<stack name="xsite">
<transport type="TCP" socket-binding="jgroups-tcp" />
<protocol ... />
<relay type="relay.RELAY2">
<site name="LON" id="0">
<bridges>
<bridge name="global" stack="bridge" />
</bridges>
</site>
<site name="NYC" id="1">
<bridges>
<bridge name="global" stack="bridge" />
</bridges>
</site>
<site name="SFO" id="2">
<bridges>
<bridge name="global" stack="bridge"/>
</bridges>
</site>
</relay>
</stack>
I think this makes mostly sense. I'm wondering though if PaulF likes the
idea of having <transport>, <protocol> *and* (now) <relay>...
I suggest changing <bridge name="nnn"..> to <bridge
cluster-name="nnn"...>. I think I'll change this in the JGroups config
as well...
I'm also thinking of removing the ids in JGroups and working only on the
basis of (short) strings as site-ids. If at all, I'll only make this
change after the Palma meeting.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
9 p.m.
On 18 Oct 2012, at 08:01, Bela Ban wrote:
Furthermore, a big +1000 to *remove* the <backup-for> element,
which I
think isn't needed (and I've said this before) …
-1001
Without it the backup cache *must* have the same name as the original cache, which is too
restrictive.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4451
days inactive
4452
days old
infinispan-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Bela Ban -
Mircea Markus -
Tristan Tarrant