Re: pn_subscription_address is empty more than is useful......

[Fraser Adams <fr...@blueyonder.co.uk>]

On 29/09/14 20:36, Rafael Schloming wrote:
> On Fri, Sep 26, 2014 at 12:51 PM, Fraser Adams <
> fraser.adams@blueyonder.co.uk> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: pn_subscription_address is empty more than is useful......

[Rafael Schloming <rh...@alum.mit.edu>]

On Fri, Oct 3, 2014 at 4:49 AM, Fraser Adams <fr...@blueyonder.co.uk>
wrote:

> On 29/09/14 20:36, Rafael Schloming wrote:
>
>> On Fri, Sep 26, 2014 at 12:51 PM, Fraser Adams <
>> fraser.adams@blueyonder.co.uk> 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