On 07/16/2012 10:39 PM, Sitapati das / Joshua J Wulf wrote:
I see (I think).
I don't have a production use case atm, I'm just experimenting. I was using
auto-delete queues so that my tests cleaned up after themselves.
I was under the (mistaken) impression that a sender gave me a handle on a
queue. If I understand this correctly, what I actually get is a handle on a
generic sender, who automatically sets the x-routing-key of the message to
the string value that I pass to the constructor. In the constructor the
sender creates a queue on the broker if a queue with that name doesn't
exist, basically as a courtesy, but the queue and the sender are decoupled
architecturally.
The sender will create the queue if it doesn't exist only if you ask it
to be specifying a create option.
In pre 1.0 AMQP, there isn't really anything corresponding to a
'sender'. The asymmetry implies messages are received from a queue, but
sent to an exchange.
To get the kind of behaviour that I was expecting, I would create a Queue
class, and it would have a receiver and a sender in it. So when I create my
auto-delete queue with this object, the queue would remain as long as I had
a handle on it. I might make a SynchronousQueue class with a browse and
fetch method, and an AsyncReadQueue and AsyncBrowseQueue class that can do
asynchronous fetching.
That would make things behave more the way I was expecting them to,
although I still wouldn't get an invalid handle on my queue object if
someone explicitly deleted the queue from underneath me.
And this might be taking things in completely the wrong direction, and I
might be better off rethinking my approach than trying to make this thing
act like something that it isn't.....
Quite possibly... While I do think that a queue that deletes itself when
there are no 'users' and where 'users' means senders or receivers is the
most intuitive, it isn't how early versions of AMQP were defined. I
think AMQP 1.0 opens the door to much more intuitive and useful behaviour.
In general I also think that for a shared communication channel,
autodelete is not the most common requirement. You usually want that
'channel' to remain independent of the lifecycle of the senders or
receivers.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
