Home/ Questions/Q 435711
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T20:24:14+00:00

I have a fairly straightforward WCF service that performs one-way file synchronization for a

  • 0

I have a fairly straightforward WCF service that performs one-way file synchronization for a bunch of smart clients. I’ve noticed that when there’s a network or service interruption during a call, the client stops being able to communicate with the server until the entire application is restarted.

The service runs with BasicHttpBinding and is hosted with IIS6 (a .svc page), using transferMode="Streamed" and messageEncoding="Mtom". The service is configured to use the default InstanceContextMode (I think it’s Per Call?) and ConcurrencyMode=Single. It’s using the default throttling behavior, but I’m in an isolated test environment that nobody else is hitting.

Clients are Windows Services. I’m using this ServiceProxyHelper to ensure connections are Close()‘d or Abort()‘d correctly when Dispose()‘d, though there are no sessions so I don’t think that even matters. When an error occurs, the Client object is disposed and then goes out of scope. After the exception is detected, the service waits a bit, then creates a new client object and tries again. So it should recover from the failure, but for some reason all subsequent calls to the service fail.

I can reproduce this reliably by starting a client, allowing it to transfer a few files, then iisresetting the server. First the client generally displays a "Service is Too Busy" error (which maps to the IIS 503 error that you get during an app restart). After that, all subsequent calls to the service time out. As far as I can tell the calls are not even being attempted by the client. I have tracing enabled and what I see is: Timeout error, followed by a "Failed to send request message over HTTP" warning, followed by another Timeout error.

The crazy thing is that when I configure the client to use Fiddler (port 8888) as a proxy in app.config, everything works as desired. So somehow Fiddler as the proxy is closing or finalizing some kind of connection that WCF on its own is not.

Thoughts?

Edit 2009-10-30 8:54PM: Changed service attributes to: InstanceContextMode=Single and ConcurrencyMode=Multiple. No difference.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well that was painful. It took me forever but finally I zeroed in on the difference between running with a proxy vs without and started poking around the <system.net> settings. It turns out that adding this configuration bit to the client fixes the problem:

      <system.net>
    <settings>
      <servicePointManager expect100Continue="false" />
    </settings>
  </system.net>

    Can somebody explain what’s going on? Why should this setting cause WCF clients to hang irreparably when there’s a service interruption?

    • 0