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

--- Comment #1 from Steve Singer <ssinger at ca.afilias.info> 2010-06-23 06:34:50 PDT ---

-- 2nd choice:
-- If we are subscribed to any set originating on this
-- event origin, we want to listen on all data providers
-- we use for this origin. We are a cascaded subscriber
-- for sets from this node.

Seems to indicate that the intention was to not listen on events from node 1
but always get them from node 2.  The issue is that if node 2 goes away (ie
dies)

If node 2 is no longer accessible then the events originating from node 1 need
to come from somewhere.

We could have node 4 add the sl_listen entry for node 1.  The problem then
becomes that node 4 might receive a SYNC event directly from node 1 before it
receives that sync event via node 2 (in normal circumstances), processing those
SYNC events mean that we'd be receiving the data direct from the origin and not
through node 2, this defeats the purpose of it being cascaded.

If we continue to ignore those syncs with the message "data provider 2 only
confirmed up to ev_seqno 5000000150 for ev_origin 1" then node 4 will never get
caught up enough to process the SUBSCRIBE message.

What I think we need to do is continue to NOT listen on the origin.   If node 2
goes away we need to issue a FAILOVER type of command that will tell node 4
that it's provider is no longer node 2 but it is now node 1.  The normal
SUBSCRIBE command doesn't work because the SUBSCRIBE command travels from the
origin (node 1) to node 4 via node 2 in queue order but it won't get processed. 

At first glance we can 

1) Have a command that gets slonik tell node 4 directly to reconfigure its
provider for set 1.   
2) Have an event originate on the new provider that is faked to look like the
next event so it will get processed.  I think this is a bad idea because even
though we are 'failing' node 2 it is possible that node 4 is still processing
events from node 2 so I don't see how your going to safely find the next event
id and also ensure that the 'real' event with that id doesn't get processed in
the meantime.

I am thinking that slonik should have logic where:   If this is a subscribe
set, and the receiver is already subscribed to the set via a different provider
then it contacts the receiver directly and reconfigures it

-- 
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.
You are the assignee for the bug.