27

I'm trying to get a better understanding of what's going on when I use a WCF proxy. I'm having trouble understanding what happens when I close (or don't close) a proxy.

  • What's going on when I call Close() or Abort() on a WCF proxy? What's the difference?
  • How does it differ between types of bindings (like, a sessionless BasicHttpBinding vs. something sessionful)?
  • Why can Close() throw in certain situations and why can it be a blocking operation?
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
nlawalker
  • 6,364
  • 6
  • 29
  • 46

1 Answers1

30

Closing WCF client
A client has an inherited responsibility of gracefully closing the connection. It is always recommended to close a proxy client. If the binding between a client and a service is transport-layer sessionful, then closing a proxy is essential to tear down the connection between both parties. Service has a payload threshold defined for concurrent connections. If the number of concurrent connections goes above this threshold linearly then the overall service performance decreases exponentially. This is why it is crucial to dispose of the connection as soon as possible. Closing the proxy also notifies the service instance that it is no longer in use and may be collected by GC (subject to service instance management). If the client does not close a connection, it is still automatically torn down by WCF timeouts (found in the configuration files).

Aborting WCF client
In the situation where there is a fault in the service-client interaction, the objects on both ends are potentially totally broken. Thus using a proxy after the exception is not advised. Given the WCF binding use transport sessions, the client after a fault would not even be able to close it (if there was no transport layer session then the client could use or close the proxy, but this is not recommended as the configuration of sessions could change). So after a fault has happened the only safe operation is to abort a proxy.

Close is a synchronous operation, it can throw if the transport session has been damaged by a fault and it is a blocking operation until a confirmatory response from service is received (true for some bindings).

oleksii
  • 35,458
  • 16
  • 93
  • 163
  • 2
    If the number of concurrent connections goes above this `threshold linearly then the overall service performance decreases exponentially.` Can you please help to understand this point. – Abhijeet Mar 08 '13 at 12:27
  • 1
    It's just something I observed in practice - load and resources usually behave in this way. If one increases the load, throughput performance increase. However, at some point (saturation point) the load gets as high as a box can normally handle. At this point you get max performance. If you keep increasing the load, the service won't die immediately but it will "buffer" the requests. This helps to solve pick load traffic as usually it lasts tiny amount of time. But in our example we will continue increasing the load and fill some internal buffers. After saturation perf degrades much faster. – oleksii Nov 09 '15 at 17:16
  • 1
    I still am not understanding what `Abort` does or, more importantly, what can go wrong if `Abort` is not called. Does it only matter if you're trying to re-use your proxy client instance, would not calling `Abort` affect new instances, and/or is it a memory leak issue? – xr280xr Feb 25 '20 at 05:00