RE: Making queue writable only if there is at least one consumer
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
0.24 release update - Release branch created, beta is available
Hi, folks. Yesterday at revision 1504342, we branched for the upcoming 0.24 release. Check it out at this URL: https://svn.apache.org/repos/asf/qpid/branches/0.24/ The beta distribution is from revision 1504344 of the release branch: http://people.apache.org/~jross/qpid-0.24-beta/ http://people.apache.org/~jross/qpid-0.24-beta-testing.txt Please note that this is pre-release software and should only be used for testing. We expect to find and fix many defects as we work toward the final GA release. My testing on Fedora 16 x86-64 completed without error. Note, however, that it is still autotools-centric. Now that we've branched, the policy for 0.24 changes is more restrictive. We're looking for bug fixes that are safe and worthy; features and improvements should wait for the next release. See the "Criteria for accepting changes" section of the release page[1] for more information. As a reminder: each 0.24 change must be reviewed by a third party and approved by the release manager before it is committed to the release branch. Send mail to the list to request inclusions. I've adjusted the 0.24 schedule to reflect the fact that I produced the beta two weeks late. RC1 is now set for the end of this month, and everything else is bumped out accordingly. Give it at try and report what you find. Your feedback very much helps us improve Qpid releases. Thanks! Justin --- [1] 0.24 release page: https://cwiki.apache.org/confluence/display/qpid/0.24+Release - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
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).
