How to protect a WCF Service from hanging?

Question

It is apparent to me that as I develop clients for my WCF services I must either maintain a singleton proxy or close my proxy prior to creation of a new one. 

 

If I consistently allow my proxies to simply go out of scope, then I find resources remain attached to the server.  On the eleventh call to the server, my client hangs and hangs the WCF Service with it.  From that point on the WCF Service no longer accepts requests and the server hosting the service (be it IIS 5, IIS 7, or Cassini) must be recycled.

 

This seems to be an unacceptable scenario. I am not sure that I can accept that rogue clients, poorly developed clients, or just misinformed developers can bring the WCF Service to its knees by such a simple oversight as not calling close on the proxy.  What if the client is being developed externally to the host by someone who doesn't know this?  What if the client is executed upon in test and this issue is never found because unit testing only performs individual tests, then the client is promoted to production?  I don't think recycling production IIS instances is an acceptable solution.

 

So, my question is this.  Does anyone know of a way that the WCF Service can recover from a situation or, better yet, prevent the situation where the client:

1. Never closes its proxy.
2. Continually creates a new proxy or each request.
3. Sends enough requests to make the WCF Service hang.

Thanks in advance.

me.

 

 

 

Answer 1

If you are hosting WCF service on Windows XP or Vista, there is a OS limit called total number of concurrent connections. This seems to be your problem. If so, try to host the service on a server OS like win2k3 and see if that helps.

This list could be helpful you. It shows limitations on different platforms:

Windows Vista Home Basic*	3
Windows Vista Home Premium	3
Windows Vista Ultimate	10
Windows Vista Professional	10
All Windows Server SKUs	unlimited

 

Answer 2

 

Thanks for the response Damir.  I believe that you are correct.  I have been working on development machines, not server machines.

 

Thank you.

me.

Answer 3

 

My pleasure "me"J

If the answer above solves your problem, please just mark it as answered.

Answer 4

Hi...

 

I came across the same issue when my client is not closing the proxy after done with service call..It worked like a charm when client side proxies are closed after each call...

 

 

I am hosting the services on Windows 2003 server ( in IIS) ...

 

This makes me think that operating system we are using might be only one of the reason for the hanging...

 

I would recommend you to look in to following section on configuration...

 

1. Instance Context mode for the service...
2. There are few options we can set for service operation ( you can set to operation level rather than service level)
 - Is Initiating
- Is Terminating

 

 

Hope this helps.,,,

 

Answer 5

Hari, thanks for the response.  I like gathering all the information I can.

 

Have you successfully used these changes you are suggesting to fix your problem?

 

Could you post examples of the configuration sections you are referring to?

 

 

Once again, thanks.

me

Answer 6

Hi Williams,

 

I am also looking in to the same issue and want to share what I found so far...

There might lot of issues that might be leading to hanging....Few of them I can see are

 

 

- If you are using tcp binding.. I would recommend you to look in to following post as well.. ( it talks about some config changes)

http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1755618&SiteID=1

 

- Client is not closing the proxy channels...

- MaxConcurrent sessions ( by default it will be set to 10.. we can increase this by modiying serviceThrottling)

 

- The defaults specify that a session which is created should not be terminated in less than 10 minutes. It's not terminated in less than 10 minutes for a good reason. If you're doing the reliable messaging, what you need to do is hold the channel open, or hold the session open for some amount of time. Network errors can do a lot of things. You can get delays; you can get repeated packages or anything. What you can do on the service side is increase the number of maximum sessions, or actual maximum number of sessions. You can decrease the in-activity time-out so the service side drops the sessions sooner so you don't hit the maximum session count so early.

 

For me, closing client proxy channel itself resolved the issue.. i am trying to see how it scales up with the load...

 

When I looked in to the direction.. what if client is not closing the channels... ??? ( I do not have any control over it) . These are my findings.

 

- How I am instantiating my Service context - Per call / Session/ Reentrant...

- I did use sessions...I looked to see if there any way I can close channel from server side .. .. "IsTerminating" property seems to be the trick for us.. ( if set to true.. this seems to close session...)

 

I tried with "IsTerminating"  set to "true" ..( how does it benifit.. enabling sessions and closing them for each call.???) . It is working fine even when client is not closing the connections once get served..

 

......this is the story so far...