http://www.slony.info/bugzilla/show_bug.cgi?id=281

           Summary: Change LISTEN strategy to reduce communications load
           Product: Slony-I
           Version: devel
          Platform: PC
        OS/Version: Linux
            Status: ASSIGNED
          Severity: enhancement
          Priority: medium
         Component: slon
        AssignedTo: cbbrowne at ca.afilias.info
        ReportedBy: cbbrowne at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


We observe that the listen networks are commonly overly populated, particularly
in view that people configuring their Slony clusters often set up (not
wrongly!) full cross-product paths from all nodes to all nodes.

The trouble with this is that the resulting listen networks wind up setting up
event listening from too many node sources, and hence the slons servicing these
nodes are opening connections to multiple other nodes in the cluster, and we
therefore have more database connections being opened than we properly ought to
need.

Instead, we propose changing the listen networks as follows:

- If a node, A, is a subscriber to a set provided from node B, then node A need
*only* listen for events through node B.  We expect most nodes in a cluster to
be subscribers, and hence this rule typically allows them to have just one
listener entry, and one connection listening for events.

The more complex case, here is if A subscribes to sets from nodes B and C.  In
that case, we ought to be able to choose arbitrarily between B and C as a
source for all events coming to node A.

- If a node, B, does not subscribe to any sets, then we may expect one of two
things to be the case:

 a) Node B is quite likely to be the origin node for subscriptions.

 b) Alternatively, perhaps Node B is not yet a subscriber to any replication
set.

 In either case, we set up node B to listen for events from all nodes with
which it can communicate.  There may be quite a few listener entries in that
case, for node B, but, as the slon for this node isn't doing terribly much
other work (as, since this is not a subscribed node, there is no regular work
for a remote_worker thread), we mayn't care very much at there being somewhat
more connections being opened.

Unfortunately, this combination of rules does not ensure that all nodes are
being listened to; there may exist a set of nodes (A, B, C) where:

1.  B subscribes to sets on a node D, not in the set (A, B, C)

2.  Nodes A and C are non-subscribing nodes (whether origin or
non-participating does not matter)

3.  There is no path in sl_path from A to C

Hence, based on the rules above, nothing is yet listening for events from node
C, and node A is unable to do so directly

4.  Assume there is a path in sl_path from B to C

THEN...

In order for the listen network to work, we need to add two extra paths:

i) B must listen for events from node C directly, in spite of our expectation
that, as a subscriber, it could get all of its events from its subscription
provider.

ii) A must listen for events from node C via node B.

There may be more recursion involved with this than I have thus far pointed out
:-(.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.