Thanks for clearing that up in a nice way.
On Fri, Dec 2, 2016 at 8:31 PM, Gordon Sim <[email protected]> wrote: > On 02/12/16 20:14, James Franco wrote: > >> I am trying to understand what happens when we send a message to a queue >> with a little more perspective. >> >> Supose I have an exchange called *my-ex *that has a queue called *my_q* >> and this queue is bound to the exchange with the binding key *my_bid*. >> Now when I send a message to the queue directrly like this >> >> ./spout my_q/someSubject This is a bind test >>>> >>> >> The message is received when I do this >> >> ./drain my_q >>>> >>> >> Now I have two questions regarding this: >> >> 1- since the address being used is my_q and there is no exchange mentioned >> (or the exchnage is blank) in the address does the broker first check the >> default exchange and then look consecutively into other exchanges until >> it >> finds the specified queue ? >> > > No. The client will send the message to the default exchange with a > routing key of 'my_q'. If a queue named 'my_q' exists, the default exchange > is guaranteed to have a binding with key 'my_q' for the my_q queue. > > 2-From my understanding so far is that when a message is sent to an >> exchange instead of a queue then depending on the type of exchange the >> message is routed to a specific queue based on the routing id and binding >> id of the queue , however if the message is sent to the a queue directly >> (instead of an exchnage name) then routing id and binding id do not matter >> and the message will be delivered to the queue. Is my understanding >> correct >> ? >> > > At the protocol level, messages are *always* sent to an exchange. The qpid > messaging API presents a higher level abstraction where you just send to or > receive from an address. If the address is a queue, and if you are using > AMQP 0-10 (rather than 1.0), this will cause the client to send to the > default exchange (which is really just a hack to allow you to emulate > sending to a queue which that protocol version did not support). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
