On 20.09.22 17:49, Frederic Monclar wrote:
> Hi Bela,
> * I suggest start only a single GossipRouter to which *all* members
> connect. The discriminator is still the cluster name and the
> destination address.
> o _Fred _:I'm going to do the test you suggest
OK
> * Of course, multiple routers can be started; clients will connect and
> register themselves with all of them,
> o _Fred _: Do you mean that if a client is registered a router via
> one port number it will be registered to all other routers which
> are running on the same machine?
No; what I meant is that you can run GossipRouters on multiple hosts and
list them all in TUNNEL.gossip_router_hosts
> That would explain why the log
> "added member to group" is present in all router's logs for the
> same added member
Perhaps you started routers on adjacent ports (e.g. 12001, 12002,
12003)? In that case, a TUNNEL.port_range > 1 would have caused clients
to register with multiple GossipRouters inadvertently.
However, running multiple GossipRouters on the same host makes no sense,
as redundancy is not provided when the host is down.
> * and then load-balance their traffic for redundancy purposes.
> o _Fred _: Does the load balancing mechanism is running by default
> with several routers on the same VM ?
Yes, by default: registration is with all GossipRouters, and traffic is
routed through one (randonly selected).
> * Can you create a small test that reproduces the issue? If some
> members can communicate with each other, and other can't, then I
> suspect a firewall issue...
> o _Fred _: communications between clients located on the same
> networks are working well, but communication with client that
> are not on the same give me lot of problems.
Perhaps turn off any firewalls, to see if this is the culprit?
> The communication
> between the client which is on the same network that the router
> and several clients which are on the other network makes problems.
This points to a network problem...
> * Also useful: run GossipRouter with option '-dump_msgs all'. This
> will dump registrations and all messages that are routed.
> o _Fred _: ok, I will do it
>
> * use RouterStubGet to dump the registrations.
> o Fred : ok, I'll do it
>
> Fred
>
> Le lun. 19 sept. 2022 à  17:06, 'Bela Ban' via jgroups-dev
> <
jgrou...@googlegroups.com <mailto:
jgrou...@googlegroups.com>> a
> <mailto:
jgroups-dev%2Bunsu...@googlegroups.com>
> > <mailto:
jgroups-dev...@googlegroups.com
> <mailto:
jgroups-dev%2Bunsu...@googlegroups.com>>.
> > To view this discussion on the web visit
> >
>
https://groups.google.com/d/msgid/jgroups-dev/415d7b8d-d334-49c4-9cac-68e363568eban%40googlegroups.com <
https://groups.google.com/d/msgid/jgroups-dev/415d7b8d-d334-49c4-9cac-68e363568eban%40googlegroups.com> <
https://groups.google.com/d/msgid/jgroups-dev/415d7b8d-d334-49c4-9cac-68e363568eban%40googlegroups.com?utm_medium=email&utm_source=footer <
https://groups.google.com/d/msgid/jgroups-dev/415d7b8d-d334-49c4-9cac-68e363568eban%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> --
> Bela Ban |
http://www.jgroups.org <
http://www.jgroups.org>
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "jgroups-dev" group.
> To unsubscribe from this topic, visit
>
https://groups.google.com/d/topic/jgroups-dev/UttnXiEUnZg/unsubscribe <
https://groups.google.com/d/topic/jgroups-dev/UttnXiEUnZg/unsubscribe>.
> <mailto:
jgroups-dev%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/jgroups-dev/cc3cc831-8542-7579-1fed-ecc9d409f770%40mailbox.org <
https://groups.google.com/d/msgid/jgroups-dev/cc3cc831-8542-7579-1fed-ecc9d409f770%40mailbox.org>.