FWIW I tend to think using subscribe in that way is really a bit of an anti-pattern because it imposes a strict ordering requirement on the startup sequence of the various distributed components in the system. To be specific, you always have to start the broker first, the subscriber second, and the publisher third. In any real system this is almost never going to be possible to guarantee. The order will most likely be completely random, and ideally you should get exactly the same result regardless.
I can't speak to Alan's particular case without more detail, but I think in general it would be most useful for users if we could define broker/client behaviour such that it is robust to randomized startup order. --Rafael On Mon, May 19, 2014 at 5:22 AM, Gordon Sim <[email protected]> wrote: > On 05/15/2014 12:48 PM, Rafael Schloming wrote: > >> On Wed, May 14, 2014 at 4:33 PM, Alan Conway <[email protected]> wrote: >> >> I've been playing with Messenger and I've found I need to do this if I >>> want to be sure it has done what I've asked it to do: >>> >>> def flush(self): >>> """Call work() till there is no work left.""" >>> while self.work(0.01): pass >>> >>> >>> I've found I need to do this after subscribe() and accept() if I want to >>> be sure the action has been carried out. (e.g. because I want to check >>> if the corresponding message has been removed from a broker.) >>> >>> Is there a better way of doing this? If not should we add something like >>> this to messenger API? >>> >>> >> You are supposed to be able to check the tracker status for your message >> to >> figure stuff like this out, although we may not (yet) expose a state that >> would correspond to the message being dequeued. >> >> >> >>> This would be analogous to the sync() call and sync arguments in the >>> qpid.messaging API. >>> >>> >> I don't think we need a sync() analog (at least not for this case) since >> it >> seems like what you care about has mostly to do with the message, i.e. did >> I get the message I want and has it reached the appropriate state. >> > > The subscribe case is not about a specific message. It perhaps comes up > more in testing than 'real world' applications, but e.g. if you want to > ensure a subscription is active before 'advertising' reachability through > that e.g. in reply-to, then it is sometimes useful. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
