On Fri, Oct 3, 2014 at 4:49 AM, Fraser Adams <[email protected]> wrote:
> On 29/09/14 20:36, Rafael Schloming wrote: > >> On Fri, Sep 26, 2014 at 12:51 PM, Fraser Adams < >> [email protected]> wrote: >> >> pn_subscription_address returns the source address of a subscription as a >>> string when a subscription is successfully made. >>> >>> Well rather, it should. >>> >>> If I were to subscribe to a node on a broker it seems to work fine, that >>> is to say if I have an address of say: >>> >>> localhost/test >>> >>> where test is a queue called test, then it works fine. Even if I do >>> >>> localhost/# >>> >>> A call to pn_subscription_address will contain the whole address >>> including >>> the dynamic node name once the broker has created the queue. >>> >>> In my case I'm using non-blocking code and pn_subscription_address will >>> get called several times in my notifier, initially returning NULL but >>> eventually returning the information I want. >>> >>> So far so good, but if I have an address of say: >>> >>> amqp://~0.0.0.0 >>> >>> or even say >>> >>> amqp://~0.0.0.0/test >>> >>> I never get a non-NULL address. >>> >>> >>> It's actually quite useful to be able to identify that Messenger has >>> successfully created a subscription, especially for asynchronous code. >>> I've >>> used it in code connecting to a broker to actually start doing something >>> useful on a dynamic queue but for peer-peer code I can't do the same. >>> >>> Perhaps with amqp://~0.0.0.0 I can assume that they have been immediately >>> created? Is that a safe assumption? >>> >>> Technically the bind can fail if there is another process bound to the >> port, so strictly speaking that isn't a valid assumption. >> >> --Rafael >> >> Thanks for this Rafael that makes sense. > > Is there a reason though why an address of the form: amqp://~0.0.0.0 or > amqp://~0.0.0.0/test will never yield a non-NULL address when > pn_subscription_address is called? > > The reason I'm interested is that all of my code is asynchronous > non-blocking stuff, now when I'm connecting a subscriber to a remote > service like a broker I'm able to identify and notify the rest of my > application that the subscription has succeeded and is active, but when my > application doing the subscribing is itself a server I can't really do this > as there's no (obvious) way I can see to validate that the subscription has > succeeded (given your comment about the potential for bind to fail). > > I can likely work around it in my particular case, but I'm curious if > there is any technical or semantic reason why having > pn_subscription_address return "amqp://~0.0.0.0" when that has successfully > bound and thus available to receive connections, or is it just an oversight? This is just an oversight. I agree it would make more sense to behave the way you describe. --Rafael
