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?
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
