Best Practice for WCF proxy lifetime - or how often to close a WCF proxy?

I've been working on a WPF application that uses WCF to access the server side logic & database.

I started with a single WCF client proxy object that I was using repeatedly to call methods on the server. After using the proxy for a while, the server would eventually throw an exception: System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://.../Service/BillingService.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.

I think this is because every service call was opening a new socket from the proxy to the server and never closing them. Eventually the server was flooded and began refusing requests.

After a brief bit of searching, I determined that I need to Close() the proxy periodically. The samples I found are degenerately small. This one provided some helpful hints, but doesn't really answer the question. I've also seen recommendations to avoid the using() pattern (and apply try/catch/finally instead) because the proxy's Dispose method may throw an exception (yuck).

It seems like the recommended pattern is shaping up like this:

[TestClass]
public class WCFClientUnitTest
{
    BillingServiceClient _service;

    [TestMethod]
    public void TestGetAddressModel()
    {
        List<CustomerModel> customers = null;

        try
        {
            _service = new BillingServiceClient();
            customers = _service.GetCustomers().ToList();
        }
        catch
        {
            _service.Abort();
            _service = null;
            throw;
        }
        finally
        {
            if ((_service != null) &&
                (_service.State == System.ServiceModel.CommunicationState.Opened))
                _service.Close();
            _service = null;
        }

        if (customers != null)
            foreach (CustomerModel customer in customers)
            {
                try
                {
                    _service = new BillingServiceClient();
                    AddressModel address = (AddressModel)_service.GetAddressModel(customer.CustomerID);

                    Assert.IsNotNull(address, "GetAddressModel returned null");
                }
                catch
                {
                    _service.Abort();
                    _service = null;
                    throw;
                }
                finally
                {
                    if ((_service != null) &&
                        (_service.State == System.ServiceModel.CommunicationState.Opened))
                        _service.Close();
                        _service = null;
                }
            }
    }

So my question still revolves around how long should I keep a client proxy alive? Should I open/close it for every service request? That seems excessive to me. Won't I incur a significant performance hit?

What I really want to do is create & open a channel and make brief burst of repeated, short, sequential service calls across the channel. Then nicely close the channel.

As a side note, while I haven't implemented it yet, I will soon be adding a security model to the service (both SSL & ACL) to restrict who can call the service methods. One of the answers to this post mentions that renegotiating the authentication & security context makes reopening the channel for every service call wasteful, but simply recommends to avoid constructing a security context.

EDIT 11/3/2010: This seems important, so I am adding it to the question...

In response to Andrew Shepherd's comment/suggestion, I re-ran my unit test with my TrendMicro AntiVirus shutdown while monitoring the output of netstat -b. Netstat was able to record a significant growth of open ports that were owned by WebDev.WebServer40.exe. The vast majority of the ports were in TIME_WAIT state. Microsoft says that ports may linger in NET_WAIT after the client closes the connection...

NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). MSL is specified to be 2 minutes. So, a socket could be in a TIME_WAIT state for as long as 4 minutes. Some systems implement different values (less than 2 minutes) for the MSL.

This leads me to believe that if every service call opens a new socket on the server, and because I am calling the service in a tight loop, I could easily flood the server, causing it to run out of available sockets and in turn generate the exception I noted above.

Therefore, I need to pursue one of 开发者_Python百科two paths: 1) attempt to batch service calls so that they reuse the server side socket 2) change my service contract so that I can return larger chunks of data with fewer calls.

The first choice seems better to me, and I am going to continue to pursue it. I'll post back what I discover and welcome further comments, questions and answers.

(Posting a completely different second answer)

If we are talking about "best practice", the real best practice with WCF is to have "coarse-grained methods". If a client is calling a method numerous times in a loop, then the entire business logic should be moved to the service itself.

For example.

[DataContract]
class CustomerAndAddress
{
    [DataMember]
    CustomerModel Customer;

    [DataMember]
    AddressModel Address;
}

[ServiceContract]
class BillingService
{
   [OperationContract]
   CustomerAndAddress[] GetAllCustomersAndAddresses();
}

or, more likely in the real world:

[ServiceContract]
class BillingService
{
   [OperationContract]
   CustomerReportData FetchCustomerReportInfo(CustomerReportParameters parameterSet);
}

Having said that, I'm still interested to see if you can pull off what you are trying.

It seems like there are several things at play here.

First the unit test I ran and monitored with netstat –b pointed out that Cassini (WebDev.WebServer40.exe) was the owner of the ports that were accumulating in the TIME_WAIT state. As the referenced MSFT kb article notes, it is normal for ports to linger after the FIN handshake while the application waits for any slow packets on the network to be delivered and the message queue to drain. The default configuration of 2 minutes explains why I saw the ports malingering after my unit test completed. While it is possible to change the MSL via registry setting, it isn’t recommended.

But, the important point that I almost overlooked is that the service was running under Cassini. When I switch my server endpoint to run under IIS7, I don’t experience any port growth at all! I can’t explain whether that means the client is reusing the ports or whether IIS7 is just better than Cassini at cleaning up the ports after they are finished. Now, that doesn’t totally answer my question regarding how often should I close the WCF proxy. It just means I don’t have to close the proxy frequently.

I can see there still being a resource tradeoff to keeping the proxy open for long periods of time.

If you have many (i.e. thousands) of clients accessing your WCF service, it may make sense to release the server resources in between calls, or small batches of calls. In which case, be sure to use the try/catch/finally mechanism and not using() because even though the service proxy implements IDisposable, the close() method can throw an exception if the service is in a faulted state.

On the other hand (as in my particular case), if you only expect to have a few clients accessing your WCF service, you don’t need the added complexity of frequently and explicitly opening and closing the service proxy. Therefore, I intend to open the proxy once when my application launches, and leave it open until the application completes. I intend to implement a service invoke helper method (similar to: Renewing a WCF client when SCT has expired? ) that will recycle the connection, just in case it ever goes into a faulted state. Then, I don’t have to worry about managing the proxy lifetime.

Please let me know if think I am misreading my test results, or if you have a better solution.

I wrote (well, found and modified) a wrapper to help with properly disposing the service. Sorry about the VB. It has some extra things in it, like a MessageViewerInspector so I can intercept the XML that flies in and out of the service. Just ignore it for now.

EDIT: I know this doesn't really answer your question of how to maintain bursts of requests, but it would certainly make using the service a little cleaner, code-wise.

Imports System.ServiceModel

Namespace WCF

    ''' <summary>
    ''' This helper fixes an issue with WCF services where an exception gets thrown
    ''' during the Dispose() call of the client, so it doesn't actually get disposed.
    ''' </summary>
    ''' <typeparam name="TProxy"></typeparam>
    ''' <typeparam name="TChannel"></typeparam>
    ''' <remarks></remarks>
    Public Class ServiceProxyHelper(Of TProxy As {ClientBase(Of TChannel), New}, TChannel As Class)
        Implements IDisposable

        Private _proxy As TProxy
        Private _inspector As MessageViewerInspector

        Public ReadOnly Property ServiceProxy() As TProxy
            Get
                If Not _proxy Is Nothing Then
                    Return _proxy
                Else
                    Throw New ObjectDisposedException("ServiceProxyHelper")
                End If
            End Get
        End Property

        Public ReadOnly Property Inspector() As MessageViewerInspector
            Get
                If _inspector Is Nothing Then
                    _inspector = New MessageViewerInspector()
                End If
                Return _inspector
            End Get
        End Property

        Public Sub New()
            _proxy = New TProxy()
            _proxy.Endpoint.Behaviors.Add(Me.Inspector)
        End Sub

        Public Sub New(ByVal endpointAddress As String)
            Me.New()
            If Not Me._proxy Is Nothing AndAlso Not String.IsNullOrEmpty(endpointAddress) Then
                Me._proxy.Endpoint.Address = New EndpointAddress(endpointAddress)
            End If
        End Sub

        Public Sub Dispose() Implements IDisposable.Dispose

            Try

                If Not _proxy Is Nothing Then
                    If _proxy.State <> CommunicationState.Faulted Then
                        _proxy.Close()
                    Else
                        _proxy.Abort()
                    End If
                End If

            Catch ex As CommunicationException

                _proxy.Abort()

            Catch ex As TimeoutException

                _proxy.Abort()

            Catch ex As Exception

                _proxy.Abort()
                Throw

            Finally

                _proxy = Nothing

            End Try

        End Sub

    End Class

End Namespace

Then you can use it like this:

    Using myService As New ServiceProxyHelper(Of MyService.MyServiceClient, MyService.IMyService)
        Try
            ' Do work
            myService.ServiceProxy.DoWork()
        Catch ex As FaultException(Of MyService.MyServiceException)
            ' Log exception
        End Try
    End Using

You have put your own answer in the question.

"What I really want to do is create & open a channel and make brief burst of repeated, short, sequential service calls across the channel. Then nicely close the channel"

That's correct.

Applying this to the example you have given, you can simplify it as:

    try
    {
        _service = new BillingServiceClient();
        customers = _service.GetCustomers().ToList();

    if (customers != null)
        foreach (CustomerModel customer in customers)
        {
                AddressModel address = (AddressModel)_service.GetAddressModel(customer.CustomerID);

                Assert.IsNotNull(address, "GetAddressModel returned null");
        }

    }
    catch
    {
          _service.Abort();
          _service = null;
          throw;
     }
     finally
     {
           if ((_service != null) &&
             (_service.State == System.ServiceModel.CommunicationState.Opened))
              _service.Close();
              _service = null;
     }

Later Edit: Oh, hang on, I just reread your question. You've said that it would fail after multiple repeated calls. I guess the above code actually causes the failure?