On Mon, May 19, 2014 at 4:14 PM, Gordon Sim <[email protected]> wrote: > On 05/19/2014 06:57 PM, Rafael Schloming wrote: > >> 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. >> > > If the subscription and the request are sent on the same connection and > are guaranteed to be written to the wire in the order in which the API > calls are made, then you are right, that would normally be sufficient > (unless the broker in use can process different sessions in parallel, in > which case they would need to be sent on the same session as well). > > If the request is for any reason on a different connection, or otherwise > 'out-of-band', then you don't have that guarantee. >
Even with multiple connections messenger could still (hypothetically) guarantee order of completion by synchronizing internally in those cases. But if we are considering multiple connections and interesting broker semantics, even the ability to synchronize on the subscribe might not get you that far, e.g. I suspect the dispatch router can't actually guarantee that when a subscribe completes the routing information has propagated to other routers. > > To be clear, I'm not arguing for any change. I was just pointing out that > subscribe() can be tracked through the current message tracker state. I'm not actually opposed to exposing the subscription status, or defining that as part of the semantics of messenger.start(). My point is more that there are a lot of cases where it is not safe in general to depend on it, and it would be good to provide other capabilities people can use to avoid this. The common testing scenario where this comes up is something like: 1. test receiver subscribes/creates a queue 2. test receiver tells sender it's ok to go ahead via out of band communication (e.g. wait/notify on a condition variable or some such thing) 3. test sender then goes ahead Given that a real distributed system can never do (2), a much better pattern to follow would be to use the namespace stuff you implemented to cause the appropriate queue to get auto created when referenced. --Rafael
