You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by William Henry <wh...@redhat.com> on 2011/12/12 18:53:32 UTC
Addressing question
Hi all,
I have been very confused about the addressing and the mapping that we have (incompletely) defined as part of the documentation. I'm told that there is no implicit magic but there is some decision making going internally to determine what an address means. So for example if there is a queue called 'test', without any bindings. but I run drain and spout on test, some things automatically happen and I get the messages.
So I was wondering what would happen if I had a queue and an exchange with the same name?
So I tried something:
qpid-config add queue william
qpid-config add queue henry
qpid-config add exchange direct william
qpid-config add exchange direct henry
qpid-config bind william henry
qpid-config bind henry william
./drain -f -c 100 william
qpid isn't sure what to do. Fair enough!:
Ambiguous address, please specify queue or topic as node type
(But it means that someone could do something like this dynamically and cause issues)
Okay so what about:
./drain -f -c 100 william/henry
Ambiguous address, please specify queue or topic as node type
How about:
./drain -f -c 100 henry/william;
Ambiguous address, please specify queue or topic as node type
Wait those aren't actually ambiguous. But actually they are. An address isn't really an exchange or a queue I'm told. However we do map an address to a queue or an exchange if we feel like it (I'm being flippant here - I mean there is some implicit mapping if it's not ambiguous). So I can create a queue that maps to an address very conveniently because of some convenient mapping rule that happens implicitly. How is that happening?
It's these implicit mapping rules that are confusing. Where are these rules defined? Why is henry/william or william/henry ambiguous? Why don't we document this stuff better? Why do we have examples that imply that an address maps to a queue?
William
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by Gordon Sim <gs...@redhat.com>.
On 12/20/2011 02:47 PM, Andrew Kennedy wrote:
> On 15 Dec 2011, at 21h42, Gordon Sim wrote:
>> On 12/15/2011 08:47 PM, Andrew Kennedy wrote:
>>> In particular, most of the documentation is for the C++ broker.
>>
>> I don't think that is the case. Apart from the example on using the XML exchange and the section on 'cluster failover', what else is specific to the C++ broker?
>
> It was my general impression. What with the examples using drain and spout, and qpid-config, to set things up, which are C++ broker utilities, right?
drain and spout are generic examples that can work with any broker
supporting the version of AMQP in use.
qpid-config can be used with the java broker to create/delete
queues/exchanges which is all I think it is used for in the examples in
the text (the listing function is based on QMF and there are some issues
there still).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by Andrew Kennedy <an...@gmail.com>.
On 15 Dec 2011, at 21h42, Gordon Sim wrote:
> On 12/15/2011 08:47 PM, Andrew Kennedy wrote:
>> In particular, most of the documentation is for the C++ broker.
>
> I don't think that is the case. Apart from the example on using the XML exchange and the section on 'cluster failover', what else is specific to the C++ broker?
It was my general impression. What with the examples using drain and spout, and qpid-config, to set things up, which are C++ broker utilities, right?
> [...]
>> The following example shows a typical address for my application, which seems overly complex:
>>
>> [complicated]
>>
>> The aim here is to deliver messages sent to 'destination' on the 'app' exchange to the 'destination.id' queue.
>
> [answers]
Thanks, Gordon.
I will digest that and see what I can do to streamline the addressing in my application. Also, I begin to suspect nobody else is using custom exchanges on the Java broker ;) Maybe once I finish a resilience plugin?
Cheers,
Andrew.
--
-- andrew d kennedy ? +447584719571 : http://grkvlt.blogspot.com/ ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by William Henry <wh...@redhat.com>.
----- Original Message -----
> On 01/05/2012 07:44 PM, William Henry wrote:
> >
> >
> > ----- Original Message -----
> >> You cannot have a single producer create both the exchange and the
> >> queue via the evaluation of an address (that would seem rather an
> >> esoteric requirement to me however).
> >
> > I've done it an it works. I've kinda had to to achieve what I
> > needed
> > to do - trying to replace RabbitMQ in an implementation. The use
> > case doesn't assume that the exchange is already there when
> > creating
> > a "consumer" with a specific queue. So the address with node and
> > link
> > does the trick - though pretty ugly looking.
>
> I suspect you have the exchange and queue both created on creating a
> *consumer* (the former as a node, the latter as part of the link),
> rather than a *producer* (for which a link queue will not be
> created).
>
ack. I think you suspect right.
William
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by Gordon Sim <gs...@redhat.com>.
On 01/05/2012 07:44 PM, William Henry wrote:
>
>
> ----- Original Message -----
>> You cannot have a single producer create both the exchange and the
>> queue via the evaluation of an address (that would seem rather an
>> esoteric requirement to me however).
>
> I've done it an it works. I've kinda had to to achieve what I needed
> to do - trying to replace RabbitMQ in an implementation. The use
> case doesn't assume that the exchange is already there when creating
> a "consumer" with a specific queue. So the address with node and link
> does the trick - though pretty ugly looking.
I suspect you have the exchange and queue both created on creating a
*consumer* (the former as a node, the latter as part of the link),
rather than a *producer* (for which a link queue will not be created).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by William Henry <wh...@redhat.com>.
----- Original Message -----
> On 12/15/2011 08:47 PM, Andrew Kennedy wrote:
> > In particular, most of the documentation is for the C++ broker.
>
> I don't think that is the case. Apart from the example on using the
> XML
> exchange and the section on 'cluster failover', what else is specific
> to
> the C++ broker?
>
> [...]
> > The following example shows a typical address for my application,
> > which seems overly complex:
> >
> > 'app'/'destination'; {
> > create: always,
> > assert: never,
> > link: {
> > name: 'destination.id',
> > reliability: unreliable,
> > auto-delete: true
> > },
> > node: {
> > type: topic,
> > x-bindings: [
> > {
> > exchange: 'app',
> > key: 'destination.id'
> > }
> > ]
> > }
> > }
> >
> > The aim here is to deliver messages sent to 'destination' on the
> > 'app' exchange to the 'destination.id' queue.
>
> Do you want the 'app' exchange to be created on first use, by either
> a
> consumer or a producer?
>
> What about the 'destination.id' queue; is that also supposed to be
> created by the producer if necessary, or just by the consumer? Is the
> lifecycle of that queue tied to the lifecycle of the consumer?
>
> If the app exchange already exists and you simply want consumers
> using
> the address to receive messages sent with routing-key destination,
> then
> all you need is:
>
> app/destination
>
> If you want to control the name of the subscription queue used you
> can
> add a link option for that:
>
> app/destination; {link:{name:'destination.id'}}
>
> If you need the exchange to be created on demand you would need to
> expand this a little:
>
> app/destination; {
> create:always,
> node:{type:topic,x-declare:{type:<exchange-type>}},
> link:{name:'destination.id'}
> }
>
> (If you don't specify the exchange type in an x-declare element
> within
> the node properties you will get a topic exchange created).
>
> You cannot have a single producer create both the exchange and the
> queue
> via the evaluation of an address (that would seem rather an esoteric
> requirement to me however).
I've done it an it works. I've kinda had to to achieve what I needed to do - trying to replace RabbitMQ in an implementation. The use case doesn't assume that the exchange is already there when creating a "consumer" with a specific queue. So the address with node and link does the trick - though pretty ugly looking.
William
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by Gordon Sim <gs...@redhat.com>.
On 12/15/2011 08:47 PM, Andrew Kennedy wrote:
> In particular, most of the documentation is for the C++ broker.
I don't think that is the case. Apart from the example on using the XML
exchange and the section on 'cluster failover', what else is specific to
the C++ broker?
[...]
> The following example shows a typical address for my application, which seems overly complex:
>
> 'app'/'destination'; {
> create: always,
> assert: never,
> link: {
> name: 'destination.id',
> reliability: unreliable,
> auto-delete: true
> },
> node: {
> type: topic,
> x-bindings: [
> {
> exchange: 'app',
> key: 'destination.id'
> }
> ]
> }
> }
>
> The aim here is to deliver messages sent to 'destination' on the 'app' exchange to the 'destination.id' queue.
Do you want the 'app' exchange to be created on first use, by either a
consumer or a producer?
What about the 'destination.id' queue; is that also supposed to be
created by the producer if necessary, or just by the consumer? Is the
lifecycle of that queue tied to the lifecycle of the consumer?
If the app exchange already exists and you simply want consumers using
the address to receive messages sent with routing-key destination, then
all you need is:
app/destination
If you want to control the name of the subscription queue used you can
add a link option for that:
app/destination; {link:{name:'destination.id'}}
If you need the exchange to be created on demand you would need to
expand this a little:
app/destination; {
create:always,
node:{type:topic,x-declare:{type:<exchange-type>}},
link:{name:'destination.id'}
}
(If you don't specify the exchange type in an x-declare element within
the node properties you will get a topic exchange created).
You cannot have a single producer create both the exchange and the queue
via the evaluation of an address (that would seem rather an esoteric
requirement to me however).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by Andrew Kennedy <an...@gmail.com>.
On 13 Dec 2011, at 16h12, William Henry wrote:
> ----- Original Message -----
>> On 12/12/2011 05:53 PM, William Henry wrote:
>>> Hi all,
>>>
>>> I have been very confused about the addressing and the mapping that
>>> we have (incompletely) defined [...]
>>
>>> Why is henry/william or william/henry ambiguous?
>>
>> See above. It's because you have both a queue and an exchange of the
>> same name in each case.
>
> Yep that and a chat with Ted yesterday helped. I had thought that (from previous conversations with people that what was before (left of) the '/' was always an exchange. And that the right hand side was an address which could implicitly be a queue. And that has been the cause of my confusion for a long long time.
>
> I had not seen the content of the above URL before.
Interesting. I had also picked up on the same misapprehension. It would be good to have more comprehensive documentation, but I found the page here quite useful:
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s04.html
Basically, until I had to write address strings to publish and subscribe from a custom exchange I had written for the Java broker, I'd never really investigated the innards of the format. In particular, most of the documentation is for the C++ broker. It would be good to split it out into a separate chapter that is broker agnostic, perhaps?
>>> Why don't we document this stuff better?
>>
>> A combination of reasons. What makes perfect sense to the author may
>> not make sense to (all) readers; we need feedback that we can act on. It
>> takes time to improve things and that time isn't always easy to find
>> in busy schedules. I think there are still some structural/procedural
>> issues that make fixing documentation more daunting than it should
>> be.
>>
>> We certainly want to do a better job, so any suggestions &
>> contributions are welcome.
>>
>>> Why do we have examples that imply that an address maps to a queue?
>>
>> An address *can* refer to a queue.
I am actually still a bit unclear as to the link/node distinctions. Would I be correct assuming these are to provide forward compatibility with AMQP 1-0 then? Also, I seem to have to give a 'type: topic' for the node when I want to force an address to be resolved as an exchange, which is misleading. The following example shows a typical address for my application, which seems overly complex:
'app'/'destination'; {
create: always,
assert: never,
link: {
name: 'destination.id',
reliability: unreliable,
auto-delete: true
},
node: {
type: topic,
x-bindings: [
{
exchange: 'app',
key: 'destination.id'
}
]
}
}
The aim here is to deliver messages sent to 'destination' on the 'app' exchange to the 'destination.id' queue. There is extra excitment with the actual exchange implementation, which isn't really relevant. But, is there some simpler address I could use here to achieve this result?
Cheers,
Andrew.
--
-- andrew d kennedy ? +447584719571 : http://grkvlt.blogspot.com/ ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by William Henry <wh...@redhat.com>.
----- Original Message -----
> On 12/12/2011 05:53 PM, William Henry wrote:
> > Hi all,
> >
> > I have been very confused about the addressing and the mapping that
> > we have (incompletely) defined as part of the documentation. I'm
> > told that there is no implicit magic but there is some decision
> > making going internally to determine what an address means. So
> > for example if there is a queue called 'test', without any
> > bindings. but I run drain and spout on test, some things
> > automatically happen and I get the messages.
> >
> > So I was wondering what would happen if I had a queue and an
> > exchange with the same name?
> >
> > So I tried something:
> > qpid-config add queue william
> > qpid-config add queue henry
> > qpid-config add exchange direct william
> > qpid-config add exchange direct henry
> > qpid-config bind william henry
> > qpid-config bind henry william
> > ./drain -f -c 100 william
> >
> > qpid isn't sure what to do. Fair enough!:
> > Ambiguous address, please specify queue or topic as node type
> >
> > (But it means that someone could do something like this dynamically
> > and cause issues)
>
> To some extent that is always going to be the case. I could delete
> and
> recreate the node you are using and change the behaviour. I took the
> view that it is better to be explicit about ambiguity. In general my
> advice would be to avoid having queues and exchanges using the same
> name.
>
> > Okay so what about:
> > ./drain -f -c 100 william/henry
> > Ambiguous address, please specify queue or topic as node type
> >
> > How about:
> > ./drain -f -c 100 henry/william;
> > Ambiguous address, please specify queue or topic as node type
> >
> > Wait those aren't actually ambiguous.
>
> They are. In both cases the named node could refer to either the
> exchange or the queue. E.g. in the first case, do you want to pull
> messages from the william queue or from the william exchange?
>
> > But actually they are. An address isn't really an exchange or a
> > queue I'm told. However we do map an address to a queue or an
> > exchange if we feel like it (I'm being flippant here - I mean
> > there is some implicit mapping if it's not ambiguous). So I can
> > create a queue that maps to an address very conveniently because
> > of some convenient mapping rule that happens implicitly. How is
> > that happening?
> >
> > It's these implicit mapping rules that are confusing. Where are
> > these rules defined?
>
> Section 2.16. - The AMQP 0-10 mapping - of the Programming Guide:
>
>
> http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s16.html
>
> There are also a couple of examples in the section introducing
> addresses
> (2.4) showing that the broker entity referred to by the address
> influences the messaging patterns.
>
> > Why is henry/william or william/henry ambiguous?
>
> See above. It's because you have both a queue and an exchange of the
> same name in each case.
Yep that and a chat with Ted yesterday helped. I had thought that (from previous conversations with people that what was before (left of) the '/' was always an exchange. And that the right hand side was an address which could implicitly be a queue. And that has been the cause of my confusion for a long long time.
I had not seen the content of the above URL before.
>
> > Why don't we document this stuff better?
>
> A combination of reasons. What makes perfect sense to the author may
> not
> make sense to (all) readers; we need feedback that we can act on. It
> takes time to improve things and that time isn't always easy to find
> in
> busy schedules. I think there are still some structural/procedural
> issues that make fixing documentation more daunting than it should
> be.
>
> We certainly want to do a better job, so any suggestions &
> contributions
> are welcome.
>
> > Why do we have examples that imply that an address maps to a queue?
>
> An address *can* refer to a queue.
Thanks Gordon this was useful.
William
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Addressing question
Posted by Gordon Sim <gs...@redhat.com>.
On 12/12/2011 05:53 PM, William Henry wrote:
> Hi all,
>
> I have been very confused about the addressing and the mapping that we have (incompletely) defined as part of the documentation. I'm told that there is no implicit magic but there is some decision making going internally to determine what an address means. So for example if there is a queue called 'test', without any bindings. but I run drain and spout on test, some things automatically happen and I get the messages.
>
> So I was wondering what would happen if I had a queue and an exchange with the same name?
>
> So I tried something:
> qpid-config add queue william
> qpid-config add queue henry
> qpid-config add exchange direct william
> qpid-config add exchange direct henry
> qpid-config bind william henry
> qpid-config bind henry william
> ./drain -f -c 100 william
>
> qpid isn't sure what to do. Fair enough!:
> Ambiguous address, please specify queue or topic as node type
>
> (But it means that someone could do something like this dynamically and cause issues)
To some extent that is always going to be the case. I could delete and
recreate the node you are using and change the behaviour. I took the
view that it is better to be explicit about ambiguity. In general my
advice would be to avoid having queues and exchanges using the same name.
> Okay so what about:
> ./drain -f -c 100 william/henry
> Ambiguous address, please specify queue or topic as node type
>
> How about:
> ./drain -f -c 100 henry/william;
> Ambiguous address, please specify queue or topic as node type
>
> Wait those aren't actually ambiguous.
They are. In both cases the named node could refer to either the
exchange or the queue. E.g. in the first case, do you want to pull
messages from the william queue or from the william exchange?
> But actually they are. An address isn't really an exchange or a queue I'm told. However we do map an address to a queue or an exchange if we feel like it (I'm being flippant here - I mean there is some implicit mapping if it's not ambiguous). So I can create a queue that maps to an address very conveniently because of some convenient mapping rule that happens implicitly. How is that happening?
>
> It's these implicit mapping rules that are confusing. Where are these rules defined?
Section 2.16. - The AMQP 0-10 mapping - of the Programming Guide:
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s16.html
There are also a couple of examples in the section introducing addresses
(2.4) showing that the broker entity referred to by the address
influences the messaging patterns.
> Why is henry/william or william/henry ambiguous?
See above. It's because you have both a queue and an exchange of the
same name in each case.
> Why don't we document this stuff better?
A combination of reasons. What makes perfect sense to the author may not
make sense to (all) readers; we need feedback that we can act on. It
takes time to improve things and that time isn't always easy to find in
busy schedules. I think there are still some structural/procedural
issues that make fixing documentation more daunting than it should be.
We certainly want to do a better job, so any suggestions & contributions
are welcome.
> Why do we have examples that imply that an address maps to a queue?
An address *can* refer to a queue.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org