You can sort of do #2 by auto-deleting the queue when the last consumer disconnects. To avoid orphaning any messages, you can set up an alternate exchange for the queue, so when the queue is deleted, any messages get rerouted to the alternate exchange. You can use other queues/bindings to direct the messages somewhere else (another data center?)
-Steve > -----Original Message----- > From: Rothkin, Steve (NY81) [mailto:steve.roth...@honeywell.com] > Sent: Thursday, July 18, 2013 1:12 PM > To: users@qpid.apache.org > Subject: Making queue writable only if there is at least one consumer > > I'm building a queuing solution involving multiple data centers. Requests that > come into one center should be processed there - if that center isn't able to > process them, it is preferable to have the requests rejected at the entry > point so that remote clients can failover to one of the other centers and > directly send their requests there. This ability is already there in the entry > point. > > Within each data center, each application service will have a single queue > with multiple consumers (some of which may be on different computers). > The queues would be hosted on a cluster of computers that does NOT > include the entry point. > > So what I need is a way to detect at the entry whether there is at least one > consumer available for the requested application. My thought was to > > > 1) Have the first consuming application process to create the queue on > startup if it doesn't exist and > > 2) to somehow have the queue become non-writable when the last > consumer disconnects from it > > #1 seems to be easily done through the create: receiver option > > I'm looking for a way to do #2 (if it is even possible, if not I'd need to > setup > another mechanism outside the queues to advertise service availability) - > either remove write permission from the queue or change its limit to equal > its current contents. I have not yet found an API method to do this (though I > am still digging). > > I did notice there is a delete: receiver option, though it isn't clear how > that > would behave with multiple consumers. And at any rate I'd prefer not to > delete the queue unless it is empty - this way if another consumer comes > online quickly, it can process the messages left in the queue (the current > implementation doesn't offer any way to redirect those messages to another > data center as the remote clients are done once the entry point returns > acknowledgement that the message has been successfully queued). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
