views:

77

answers:

1

I setup WCF service tracing because 1 client out of about 30 wasn't able to finish the connection to the server. After setting up test case on that client, the WCF trace report gave me these exceptions:

An operation was attempted on a nonexistent network connection

and then

The I/O operation has been aborted because of either a thread exit or an application request

I found this MSDN question and solution that applies to Windows 2000 Server and Terminal Services and offers a hotfix to fix the issue.

I'm using Windows 2003 Server, so the hotfix doesn't apply to me. Does anyone know what is happening to this 1 client while the other 29 connect just fine?

Edit: The client returns this exception when trying to open the connection to the server:

An error occurred while receiving the HTTP response to http://endpointaddress/. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

A: 

I recently ran into this problem. The core problem was the context in which the calls were made.

I had a lot of code that looked like this:

New()
{
    IPC_Server.LoadFirstSetOfData();
}

IPC_Server_LoadFirstSetOfData_Completed(Object sender, System.ComponentModel.AsyncCompletedEventArgs e)
{
    IPC_Server.LoadSecondSetOfData();
}

IPC_Server_LoadSecondSetOfData_Completed(Object sender, System.ComponentModel.AsyncCompletedEventArgs e)
{
    ShowDataToUser();
}

The problem with this was that I was calling the 2nd IPC function while I was inside the 1st callback. For some reason, doing this "corrupts" the next call. By moving our IPC calls out of the callbacks, we resolved this issue.

Now how you choose to move calls out of the callbacks is up to you. Maybe a contract change? Having a timer that watches for the 1st callback to come in, then execute the 2nd IPC call from the timer? The choice is yours.

Onion-Knight