You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2014/09/26 18:51:07 UTC
pn_subscription_address is empty more than is useful......
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?
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......
Posted by 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
Re: pn_subscription_address is empty more than is useful......
Posted by 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......
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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