On Mon, May 19, 2014 at 11:59 AM, Gordon Sim <[email protected]> wrote:
> On 05/19/2014 04:25 PM, Rafael Schloming wrote: > >> 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. >> > > No, I don't think that is the case. Consider a discovery case, where there > are many 'agents' up and running, and some component wants to get a list of > them. > > One common solution is to subscribe to some topic on which agents > advertise themselves, then send a request that every agent re-announce > themselves. (E.g as in the reservations example for the qpid.messaging > client). > > If you can be sure that the subscription is active before you send your > request, you may miss announcements. So while you do indeed want to start > the publisher (of the request) before the subscriber (to the announcement), > these are in the same process. That doesn't require the same kind of synchronization, it just requires that the client implementation doesn't internally reorder execution of the given API requests. I believe the same reservations example (as well as various similar reply-to scenarios) work fine with messenger for exactly this reason (it doesn't reorder what you ask it to do). --Rafael
