Purge the ServiceBuse Queue?

Question

Hi,

I'm trying to find a way to purge all messages from an AppFabric queue I've created.   I've found this link from Clemens a couple of years ago:

http://vasters.com/clemensv/PermaLink,guid,b703725d-3e6a-4dbb-a613-890c31505fe8.aspx

Which indicates this used to be possible using the QueueClient created by the QueueManagementClient.  The QueueManagementClient looks like it's been broken up into different classes with the latest CTP.  The QueueClient that is created using the MessagingFactory doesn't include this method.  Is there another recommended mechanism for purging the queues?

Thanks,

Ariane

Answer 1

Well, you could always delete and recreate the queue.

-Dan

---

If this answers your question, please Mark as Answer

Answer 2

Thank you for your quick response, Dan. 

I could delete the queue(s), but it raises the possibility that someone might submit to the queue during the delete/create and get an exception.  I would prefer to have a way to drain the queue programmatically to avoid the necessity of catching that particular error in the client submission code (are there errors if there are race conditions in the queue creation/deletion, so I need to look for more than one type of exception? <-- this is the type of question I would like to avoid, if at all possible.). 

If .purge() isn't available, or some other drain mechanism doesn't exist, please let me know.

Thanks,

Ariane

Answer 3

Hi Ariane,

Thanks for providing the feedback. Unfortunately our current CTP release does not include an API to purge the queue explicitly. This feature may get included in a later release.
There are couple of ways to workaround this limitation (in order of preference): 1) look into setting an entity level TTL (QueueDescription.DefaultMessageTimeToLive) to ensure that messages do not linger around in the system longer than a reasonable amount of time 2) delete and re-create the queue 3) Create a receiver in ReceiveAndDelete mode and receive all the messages.

I know that none of these workarounds are as elegant as being able to just invoke one API that does it all. So, I would love to hear about your scenarios where you would need this capability.

Thanks
--
Chowdhury

Answer 4

I'm not clear on how Purge would not be a race any more than programmatically using mechanism 3, above.

Answer 5

Hi Ralph,

Can you please provide more context on your comment? exactly what scenario do you have in mind?

Generally speaking, you are right that as long as we have concurrent users invoking two different operations (be it through an explicit Purge API or option 2 or 3 above) the race is unavoidable. E.g. if we get two simultaneous requests one for purge (imagine if it was there) and one for send message to the same queue the end result could be 1) empty queue OR 2) a queue with 1 message in it. A race between a purge and receive gets even more interesting when you start taking sessionful receivers into account :) e.g. If I have gigantic group of messages all belonging to same session and we get a request for Sessionful receive and Purge at the same time you could either end up with empty queue and receiver timing out or purge not having any effect at all (because pre-empting a sessionful receiver is not a very attractive solution IMHO).

however, if your comment was in response to Ariane's comment on the race between a queue re-creation and a send; then I think in that particular scenario an explicit Purge would have at least shielded the sender to some extent. I say to some extent because a resilient sender would still need to handle a queue disappearing at any moment (some other code piece may delete the entity) anyway and take appropriate actions. There are several other factors to keep in mind as well and depending on these varying factors the recommended workaround would change too. Hence it would be really great to learn about the scenarios that users have in mind so that we can gauge the necessity of this functionality better.

Thanks

--

Chowdhury

Answer 6

Thank you for the in-depth response Chowdhury.  You have an excellent point about the sender needing to be resilient for a queue disappearing in any case. 

The purge functionality is mostly for testing and management rather than day-to-day operations.  I'm modifying our system work with either MSMQ, or ServiceBus.  The MSMQ code is already in place, and while I have the basic queue functionality done for ServiceBus, I'm only now starting on the management functionality.  This happened to be the first piece of a couple of sections that weren't obvious to me while working ny way through the APIs. 

Thanks,

Ariane

 

Answer 7

Chowdhury,

 

Yes, you've hit my point on the nose and your response is exactly what I expected but with actual precision and details involved :-).

I was thinking about the general issues involving having to always have a handle on the queue disappearing underneath you in any case. Whilst a purge method is a nice feature for destroying a queue without really caring about it, I was imagining that in general you'd really have to have a reader and sender that systematically handle the disappearance of the queue.

Mind you, given the testing scenario, having a basic method to purge would be darned useful, but I'd call it something like, "ForcedPurge" -- make it clear that other readers/senders may experience sideeffects. :-)

Nice discussion. Thanks!

Answer 8

I have to admit I was hoping for something that would, behind the scenes, tag which was the last message sent in, then drain all of the messages up to that point.  The queue would actually stay in tact (therefore any errors about the queue not being there are really uh-oh moments) and the users shouldn't have any disruption.  Probably not terribly useful in production though.  Thanks again for both of your suggestions. :)

Answer 9

You could just go through topics and redirect behind the scenes perhaps.

-Dan

---

If this answers your question, please Mark as Answer