Provide gracefull shutdown feature to Message Pump in Queue and Subscription Clients
There is not a good way to deal with a graceful shutdown of a Worker role using the OnMessage approach of processing queue messages off the service bus. It would be nice if you could call StopProcessing, or something similar on the QueueClient or SubscriptionClient so that they would stop their internal receive loop, but finish processing the messages they may already be processing. A count property of active processing messages would also be helpful so that in an OnStop method on the worker role you could call the StopProcessing and enter a loop till the active processing messages was zero.
Perhaps actually creating a new class called a MessagePump which accepted a QueueClient or SubscriptionClient as part of the constructor would be a good route to provide a better break down of responsibilities.
This is a great suggestion Mike. This does not only apply to OnMessage APIs, it will be applicable for making pending Receive(timeout) calls too in the case of a graceful shutdown when several of these are pending. Any specific requirements or suggestions on what API shape/pattern you would like to see are appreciated.
This is marked planned... any updates?
The same goes for automatic session handling. That is RegisterSessionHandler and RegisterSessionHandlerFactory which also can't be told to 'Stop', you just have to close the connection and wait for everything to stop failing (with each of the sessions having the same problem as the original post)
Chris Patterson commented
This would be extremely helpful. I've implemented my own counting system to handle shutdowns as gracefully as possible (basically to avoid exiting the process while messages in flight -- even after the message receiver is closed). I would actually prefer that locked messages are NOT automatically rejected, because the whole point is to "finish what you're doing" and then let me exit cleanly.
Aaron Stainback commented
It looks like even now when I close the queueclient underneath the message pump still receives messages for a bit.
It would also be good if locked prefetch'ed messages were abandoned automatically when doing this graceful shutdown.