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. 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..... On Mon, Jul 16, 2012 at 10:30 PM, Gordon Sim <[email protected]> wrote: > On 07/16/2012 12:04 PM, Sitapati das / Joshua J Wulf wrote: > >> Hi, I noticed that if I create an autodeleting queue and it gets >> auto-deleted, my attempts to send to it don't cause an exception, and my >> messages seem to disappear into the ether. Is that expected behaviour? >> > > Expected by whom?! > > It is an unfortunate aspect of the model in pre-1.0 AMQP, where you send > messages to an exchange, never a queue. The default exchange is a little > trick to work around that, but you are still sending to an exchange. > > While it is an error to send to a non-existent exchange, it is not an > error to send to an exchange that is not able to route the message to a > queue. > > In the messaging API we try to work around that by checking the queue > exists when you create your sender. However once created, we don't want to > check for every message just to handle this sort of case. > > We could in theory make use of rejects for this case, but haven't done so. > > > I'm using the python client. Here's a minimal test case that reproduces >> the >> behaviour: >> >> import sys >> from qpid.messaging import * >> >> connection=Connection("**localhost:5672") >> connection.open() >> try: >> session=connection.session() >> tx=session.sender("test-queue; {create:always, >> node:{x-declare:{auto-delete:**True}}}") >> tx.send("test message!") >> x = raw_input("Press Enter to continue") >> tx.send("test message 2") >> except MessagingError, m: >> print m >> connection.close() >> >> When the program pauses for keyboard input, I subscribe and unsubscribe >> using drain -c 0 test-queue in another window. This causes the queue to >> auto-delete. >> >> I would expect an exception to be thrown when I try to send the second >> test >> message, but it isn't. >> >> Is this a bug? Am I doing something wrong? >> > > The auto-delete is also a little unintuitive unless you are very familiar > with the pre-1.0 AMQP model. In this case the queue will be deleted, as you > point out, when the consumer count drops back to 0, even though the queue > is still in a real sense 'in-use' by the sender. > > Do you have a use case that requires auto-deletion of a shared queue? If > so perhaps some more detail on that could help making suggestions on how > best to handle it. > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
