Re: [jgroups-users] unexplained port usage

Ok, am finally realizing how little I knew about the way the stack is put
together. Hopefully simple questions below.

On Tue, Jun 14, 2016 at 10:29 AM, Questions/problems related to using
JGroups <[email protected]> wrote:

> >     the only other port opened should be by FD_SOCK. This can be set by
> >     start_port.
> >
> >
> > Thanks, I can watch FD_SOCK#run in the debugger and see where it's
> > picking up the random port. For whatever reason, I never realized that
> > FD_SOCK was using a different port than the bind port used in TCP -- I
> > guess I thought the TCP socket was used for everything.
>
> Nope - you can use FD_SOCK also with UDP as transport. And even if TCP
> is used, FD_SOCK cannot rely on TCP closing a connection as idle
> connections may get reaped and closed.
>

I copied this originally from tcp.xml, and ended up with:

        stack.addProtocol(new TCP()
                [values ommitted]
            .addProtocol(new TCPPING()
                [values ommitted]
            .addProtocol(new MERGE3()
                [values ommitted]
            .addProtocol(new FD_SOCK())  [all default values used]
            .addProtocol(new FD
                .setValue(<max tries and timeout here>)
            .addProtocol(new VERIFY_SUSPECT()
                .setValue("timeout", <timeout>))
            .addProtocol(new BARRIER())
            [etc]

I guess I thought that FD needed FD_SOCK below it, but now see that FD* and
VERIFY_SUSPECT are all unrelated and just need TCP below them.

Question 1: I let users specify values for FD, but not FD_SOCK. Does that
mean that really long values (set by user) for FD might not matter if
FD_SOCK discovers a failure first?

Question 2: If users only open very few ports in their firewall, for
instance bind_port in TCP and database ports, failover still happens anyway
though it sounds like FD_SOCK can't work. Is it working because FD can
still talk to other members using TCP's bind_port?

Question 3: Moving forward, based on other unrelated discussions with you,
I've replaced FD with FD_ALL. Can I just pull FD_SOCK out of there and
things should work ok? The current customer asking about the random ports
would like to not have anything random, and it seems like I could just pull
that. Another product we write here just uses this in the stack, and it's
been working fine:

    [TCP and TCP_GOSSIP below this]
    <MERGE2 min_interval="10000" merge_fast="true" max_interval="30000"/>
    <FD timeout="30000"/>
    <FD_ALL timeout="30000"/>
    <BARRIER/>
    [other stuff]

...though I don't know what the advantages are of multiple FD* protocols in
there. So, to get it all in one place, I'm proposing this stack (values
removed, but it's the same as pasted in the initial mail in this thread
with FD -> FD_ALL). Do you see any issues?

        stack.addProtocol(new TCP()
            .addProtocol(new TCPPING()
            .addProtocol(new MERGE3()
            .addProtocol(new FD_SOCK())
            .addProtocol(new FD_ALL2()
            .addProtocol(new VERIFY_SUSPECT()
            .addProtocol(new BARRIER())
            .addProtocol(new NAKACK2()
            .addProtocol(new UNICAST3())
            .addProtocol(new STABLE()
            .addProtocol(createAuthProtocol(efmNode))
            .addProtocol(new GMS()
            .addProtocol(new MFC()
            .addProtocol(new FRAG2())
            .addProtocol(new STATE_TRANSFER());


Thanks again,
Bobby

p.s. I think you mentioned once we might not need STATE_TRANSFER, but I do
use it so that new members get a copy of a state object whenever they join,
and the coordinator can tell everyone to update their copy when needed.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine

_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users