WCF Wait for operations to finish when closing ServiceHost

Question

I create a WCF SOAP server with an operation that takes some time to perform:

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    string LongRunningOperation();
}

[ServiceBehavior(
    ConcurrencyMode = ConcurrencyMode.Multiple,
    UseSynchronizationContext = false,
    InstanceContextMode = InstanceContextMode.Single)]
class MyService : IMyService
{
    public string LongRunningOperation()
    {
        Thread.Sleep(20000);
        return "Hey!";
    }
}

class Program
{
    static void Main(string[] args)
    {
        MyService instance = new MyService();
        ServiceHost serviceHost = new ServiceHost(instance);
        BasicHttpBinding binding = new BasicHttpBinding();
        serviceHost.AddServiceEndpoint(typeof(IMyService), binding, "http://localhost:9080/MyService");
        serviceHost.Open();
        Console.WriteLine("Service running");
        Thread.Sleep(10000);
        serviceHost.Close();
        Console.WriteLine("Service closed");
        Thread.Sleep(30000);
        Console.WriteLine("Exiting");
    }
}

The ServiceHost is opened, and after 10 seconds I close it.

When calling serviceHost.Close(), all clients currently connected, waiting for LongRunningOperation to finish, are inmediately disconnected.

Is there a wait of closing the ServiceHost in a cleaner way? That is, I want to disable the service listeners, but also wait for all currently connected clients to finish (or specify a maximum timeout).

score 4 · Answer 1 · answered May 16 '11 at 14:18

Im surprised calling ServiceHost.Close is not letting LongRunningOperation complete.

The whole architecture is setup to allow things time to gracefully shut down (e.g. the difference between Close and Abort transitions.). According to MSDN docs:

This method causes a CommunicationObject to gracefully transition from any state, other than the Closed state, into the Closed state. The Close method allows any unfinished work to be completed before returning.

Also there is a CloseTimeout on the ServiceHost for precisely this. Have you tried setting the CloseTimeout to be greater than 20 seconds? (According to Reflector the default CloseTimeout for ServiceHost is 10 seconds...)

Unfortunately, the behavior is the same with _serviceHost.Close(TimeSpan.FromSeconds(30.0));_ I was expecting the behavior described in MSDN docs. — Álvaro Iradier, May 17 '11 at 07:25

score 2 · Answer 2 · answered May 16 '11 at 12:00

2

What you are doing seems all wrong to me. The ServiceHost should never close abruptly. It is a service and should remain available. There is no real way to close gracefully without some participation from the client. When I say close gracefully, this also subjective from a clients perspective.

So I dont think I understand your requirements at all, however one way would be to implement a publish/subscribe pattern and when the host is ready to close, notify all subscribers of this event so that all connections could be closed by each respective client. You can read more about this here http://msdn.microsoft.com/en-us/magazine/cc163537.aspx

Again, this approach to hosting a service is not standard and thats why you are finding it hard to find a solution to this particular problem of yours. If you could elaborate on your use case/usage scenario, it would probably help to find a real solution.

answered May 16 '11 at 12:00

Glav

743
5
4

Agreed, a WCF service should not shut itself down abruptly. – DaveRead May 16 '11 at 12:05
The service is a simple stateless request-reply web service , in which clients request a purchase operation. Ocasionally, for manteinance reasons, we need to shutdown the application offering this services. It is ok if clients can not connect to the web service (purchase is rejected), but on shutdown, we must wait for the active purchases to finish (this can take just a few seconds), and at same time stop accepting new requests. Interrupting a request while it is waiting for the response should be avoided if possible. – Álvaro Iradier May 16 '11 at 12:14
Well I think the pub/sub scenario should suffice. Once you are ready to shutdown, you should not accept anymore subscriptions and also notify any existing subscribers that you are shutting down. This could be accompanied by some timeout factor. If the subscriber does not respond in a timely fashion, then you force the issue as you have already done. As a service, you should maintain consistency and if forcing your clients to reconnect requires this, then that is what you need to do. A well written client should always assume failure is a viable code path. – Glav May 16 '11 at 12:39
1

pub/sub doesn't work for basic and wsHttpBinding i believe so Chris Dickson idea seems to be much more useful – Jack0fshad0ws Jun 11 '12 at 02:20
2

-1: The requirement is perfectly legitimate. Imagine trying to implement something akin to IIS worker process recycling. A new instance of a service starts; all requests shift to the new instance. The retiring instance must wait until all running operations are complete before closing. The above pub/sub design does not fulfill the requirement; it only tells the clients *when* the service is shut down. It does not avoid down time. – JohnC Jul 31 '13 at 20:50

score 2 · Accepted Answer · answered May 16 '11 at 13:00

2

In principle, I think something like the following should be possible, though I haven't implemented it to confirm all the details:

Implement a custom IOperationInvoker wrapping the Dispatcher's normal OperationInvoker (you'll want an IServiceBehavior to install the wrapped invoker when the service dispatcher runtime is built)
the custom invoker would mostly delegate to the real one, but would also provide "gate-keeper" functionality to turn away new requests (e.g. raise a some kind of exception) when the service host is about to be shut down.
it would also keep track of operation invocations still in progress and set an event when the last operation invocation finishes or times out.
the main hosting thread would then wait on the invoker's "all finished" event before calling serviceHost.Close().

answered May 16 '11 at 13:00

Chris Dickson

11,964
1
39
60

This was quite the way I was trying to do it. I just hoped there was a simpler way. For example, closing the ChannelListener associated to an ServiceHost seems to inmediately close all channels too. I would expect it to close only the _listener_, not the active channels. – Álvaro Iradier May 16 '11 at 13:11
Frequently channel listeners are shared, so closing it closes all the channel stacks using it. That might explain why u see active channels close – Jack Ukleja May 16 '11 at 13:57
1

Technically speaking, this doesn't actually wait until the response has actually been sent back across the channel to the client. _Is_ there, in fact, any way to wait for that?? – Jonathan Gilbert Sep 02 '14 at 18:08

score 1 · Answer 4 · answered May 16 '11 at 11:48

1

You are describing client side functionality. Sounds like you should wrap the servicehost object and then have your proxy rejecting new requests when it "is closing". You don't close the real servicehost until all calls have been serviced.

You should also take a look at the asynch CTP. To put this kind of logic inside a consumer side "Task" object will be much easier with the upcoming TaskCompletionSource class.

Check this video from dnrtv out. It's not about wcf, but rather about the upcoming language and class support for asynchrony.

answered May 16 '11 at 11:48

Tormod

4,551
2
28
50

That's what I'm trying to do: wrapping the service host bindings or channels. But I was looking for a simpler or better way. By the way, why do you think it's a client side functionality? I can't control the client behavior (I don't event develop them), I just want to make a _clean_ exit on the server side, first shutting down the listener, then waiting until all requests are finished. – Álvaro Iradier May 16 '11 at 11:55

WCF Wait for operations to finish when closing ServiceHost

4 Answers4