I'm confused, are we saying that there's a possible case where a SUBSCRIBE, WAIT FOR EVENT then a SYNC and WAIT FOR EVENT to each subscriber might not indicate that the subscription has finished?

I do this with the timeout=0 parameter before going straight onto a MERGE SET, so far I've seen no issues......

----- Original Message ----
> From: Christopher Browne <cbbrowne at ca.afilias.info>
> To: Troy Wolf <troy at troywolf.com>
> Cc: slony1-general at lists.slony.info
> Sent: Wednesday, 25 June, 2008 6:59:12 PM
> Subject: Re: [Slony1-general] Re: Slony1-general Digest, Vol 16, Issue 27
> 
> "Troy Wolf" writes:
> >>> If, like the user in the link you provided, you are trying to
> >>> SUBSCRIBE, then use WAIT FOR EVENT to know when the SUBSCRIBE has
> >>> completed, then your problem is that this does not work. WAIT FOR
> >>> EVENT is unable to reliably know when the subscribe has completed, and
> >>> you cannot MERGE SET until the SUBSCRIBE completes.
> >>>
> >>> You'll probably notice that if you wait long enough--usually a few
> >>> seconds depending on your data size--the MERGE will work.
> >>
> >> Correct on both counts.
> >
> > Then you do not have a problem. What I tried to convey is that you
> > cannot do WAIT FOR EVENT. To my knowledge, all you can do with a
> > subscribe is manually wait for it to finish. You can do this by
> > watching the logs and noticing when the subscribe completes.
> > Alternatively, you can do what I do--I have a script that does the
> > subscribe then pauses waiting for me to hit ENTER to continue with the
> > MERGE. I simply wait 10 seconds or so then hit ENTER. If the MERGE
> > fails, I just assume the subscribe is still in process and go back to
> > the code that prompts the user to wait and hit ENTER when ready for
> > the MERGE. If I were to automate this script, I'd probably catch the
> > MERGE failure, go into a wait, then try again. Each time it fails, I'd
> > double my wait. Perhaps fail 10 times before giving up with a fatal
> > error.
> 
> We're trying to get things to a point where you *could* use WAIT FOR
> EVENT to validate that subscriptions have completed.  (At least, as
> long as there wasn't some other failure; if there are 10 error
> conditions, in a complex distributed system, we can't always hope to
> catch them *all*!)
> 
> You can't expect to WAIT FOR EVENT against the SUBSCRIBE_SET event;
> the process of subscription is spread across multiple events, and the
> event whose confirmation would *directly* indicate completion of the
> subscription isn't available within the slonik script.
> 
> However, there *is* a way to WAIT FOR EVENT that you should be able to
> expect to work, and if it doesn't there's something buggy going on.
> 
> You submit the subscription, but THEN you submit a SYNC event.  *That*
> event has got to get processed *after* the subscription work is done.
> And you can wait on THAT.
> 
> Thus:
>   
>   include ;   # Pull in configuration
>   # Get the subscription going
>   subscribe set (id=1, provider=1, receiver=2, forward=yes);
> 
>   sync(id=1);    # Submits a SYNC event
>   wait for event (origin=all, confirmed=2, wait on=1);   # Waits for that event 
> to be confirmed on node #2
> 
> No doubt I should add this to the documentation :-).
> -- 


      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html