--
Galder ZamarreƱo
Infinispan, Red Hat
----- Original Message -----
1) Is it really desired to keep the site list in client
configuration?
Not sure if it was totally clear but the entire site list would not be required. The
client must contain at least 1 node's address in that site, so that it can then get
the topology of the rest.
It has always seemed to me great that I can provide only single
hotrod
server address to the client and it will figure out all the other nodes.
I can imagine a configuration with one or few well-known nodes (possibly
with capacity factor 0), and the heavy lifting to be done by an elastic
cluster. Especially in AWS or GCE like environments it simplifies the
configuration. The same could hold for the backup sites, though I
understand that this has two downsides:
a) If x-site interface is different from the interface accessible by
clients, we need a mechanism to publish the external-host:external-port
information
^ A server can define it's external host and port, but we call them proxyHost and
proxyPort.
b) if this information is per-client, it's easy to set up the
order of
backup sites (according to geographical location, to keep the cluster as
close as possible). If that's server based, it may not be possible to
declare that accurately.
^ Not sure I understand what you mean by that.
2) There should be a way to tell the clients that the original site is
back online, without bringing down the backup site.
^ That's easy to do, simply put the backup site offline and the client should bounce
back to original site.
However, that puts
us back to point 1b) - how should the client know that the another
online site is actually closer, if it does not have it on the list.
Maybe, having an optional list that would declare the priority, with
site names, would be beneficial (client would have
foo.bar.sites=BRQ,LON,SFO but wouldn't have to care about IP addresses).
^ I'm not sure about the real usability of that.
Radim
On 09/07/2015 06:26 PM, Galder Zamarreno wrote:
> Hi all,
>
> I've written a wiki describing how XSite Hot Rod client failover could work
> [1].
>
> If you have any comments/doubts/question, please reply :)
>
> Cheers,
>
> [1]
>
https://github.com/infinispan/infinispan/wiki/XSite-Failover-for-Hot-Rod-...
> --
> Galder ZamarreƱo
> Infinispan, Red Hat
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev