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

           Summary: Create a CANCEL SUBSCRIPTION command
           Product: Slony-I
           Version: devel
          Platform: All
               URL: http://lists.slony.info/pipermail/slony1-hackers/2007-
                    May/000011.html
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: medium
         Component: slon
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: cbbrowne at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


This command will inject a CANCEL_SUBSCRIPTION event at event node #3
which will cancel any SUBSCRIBE SET events for set #2 on node #4.

1.  SUBSCRIBE SET event "hook"

We would then add a "hook" at the beginning of the code that detects
SUBSCRIBE SET events; this hook would search the provider node to see
if it has any CANCEL_SUBSCRIPTION events for the set in question that
are newer than the present SUBSCRIBE_SET event.  If that be the case,
it would not bother performing anything further of the subscription.[1]

There wind up being two possibilities:

- Supposing the SUBSCRIBE SET wasn't yet in progress when the CANCEL
  SUBSCRIPTION request came in, no (further) attempt would be made to
  set up the subscription.  Perfect!  That's exactly what we asked for.

- Alternatively, it is possible that the SUBSCRIBE SET request may
  have already completed.  If the subscription was in progress at the
  time that the CANCEL request came in, there isn't much of a way (short
  of polling periodically inside the code that processes this) to force
  cancellation.  One might force this by signalling the slon with
  SIGTERM/SIGKILL; when it restarts, the re-attempt to process the event
  would take us back to the first case...

  ... But absent of that, the subscription may indeed complete.
  We nonetheless need to eliminate the subscription as other nodes will
  likely by this time have been informed of the elimination of this
  subscription.  [2]

  Thus, we need to perform the equivalent to "UNSUBSCRIBE SET" at that
  point.

2.  SYNC event "hook"

We'll wind up needing a similar hook in SYNC to what's in SUBSCRIBE
SET, I think, so that if there is an outstanding CANCEL_SUBSCRIPTION
for the local node's subscription, we arrange to do the equivalent to
"UNSUBSCRIBE SET".

3.  CANCEL SUBSCRIPTION event

On the node where the set is, this will either be a NO-OP, if the
subscription is already cancelled, or this will do "UNSUBSCRIBE SET,"
as with the earlier hooks on SUBSCRIBE SET and SYNC, if it is still
active.

On nodes other than the receiver node for the subscription, the CANCEL
SUBSCRIPTION event would perform the equivalent to "UNSUBSCRIBE SET"
to indicate the cancellation of the subscription.[3]

Footnotes: 

[1] Note that if someone accidentally submitted a whole series of
SUBSCRIBE SET requests, it only takes ONE request to CANCEL
SUBSCRIPTION to turn them all into NOOPs.

[2] Note that we can't simply say "Oh, the subscription *DID* work,
we'll keep that!" as the effect of CANCEL SUBSCRIPTION will have been
to drop info about the subscription from other nodes.  We *must* kill
off the subscription even though it might have worked.

[3] Open question: Should the CANCEL SUBSCRIPTION event wait until its
location in sequence to be processed on the other nodes (e.g.  - nodes
other than the specified receiver), or should we have it invoked via
the hook in SYNC?  I'm not certain...


-- 
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.