On 4/26/2010 5:05 PM, Steve Singer wrote:
> Jaime Casanova wrote:
>> On Mon, Apr 26, 2010 at 3:46 PM, Steve Singer <ssinger at ca.afilias.info> wrote:
> 
>> 
>>> I'm inclined to say that 2 is the correct solution.  However, if you do
>>> a subscribe and your copy set fails (as happened to Jamie) there is no
>>> easy way to not subscribe.
>> 
>> why is that?
> 
> Say you subscribe to a set and the copy set keeps failing due to some 
> error (maybe you didn't mean to subscriber to that set).  What will you 
> be able to do?  If you try issuing an unsubscribe command it will (if we 
> make the above change) just fail with a message like 'The subscription 
> is still in progress, you can't unsubscribe until it completes'.  The 
> problem being it will never complete because it keeps failing.

I am leaning towards allowing the UNSUBSCRIBE as it is now (issued 
against subscriber), then cleanup in case of the missing sl_subscribe 
row on ENABLE_SUBSCRIPTION in the form of generating an implicit 
UNSUBSCRIBE and moving on. This is effectively aborting the subscribe.

If we deny the UNSUBSCRIBE while the subscription is in progress, then 
there is no way left to abort a continuously failing subscription other 
than manually deleting stuff from sl_event (as it is now). We would have 
to add this feature.

On the other hand if we allow the UNSUBSCRIBE in the way above, then it 
most likely has been processed by the data provider while the copy_set 
was running and there is a good chance that said data provider throws 
away log data because according to its book keeping, everyone had 
confirmed it.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin