WCF service instance will not close despite only calling oneway method

Question

I have a WCF service running inside a windows service on a remote machine. In the WCF service's contract, I have a method that takes a long time to run set up as

[OperationContract(IsOneWay = true)]
void Update(myClass[] stuff);

Everything works fine, the method gets called, I can see what it needs to do start getting done.

The problem is when I go to close the instance of the WCF service in my code, it times out and I get:

The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:02:00'.

I thought the one way contract allowed me to fire and move on. Is there something I am missing? If not are there workarounds for this?

Answer 1

Your "Update" is a method on the service.

When you open the wcf client, a connection to the service remains open until you call Close (or Abort).

You are probably not calling close, and it is therefore remaining open until it timesout.

Answer 2

The ServiceContract attribute on your service's interface definition defaults the SessionMode property to SessionMode.Allowed, i.e.,

[ServiceContract(SessionMode = SessionMode.Allowed)]
public interface IMyContract
{
    [OperationContract(IsOneWay = true)]
    void Update(myClass[] stuff);
}

According to Juval Lowy's Programming WCF Services,

...when the SessionMode property is configured with SessionMode.Allowed, it merely allows transport sessions, but does not enforce it. The exact resulting behavior is a product of the service configuration and the binding used.

Thus, if you are using the WSHttpBinding with security or reliable messaging, the NetTcpBinding, or the NetNamedPipeBinding, then the service will behave as a per-session service. This simply means that as long as the client proxy has not been closed, a session will still be in place between the service and the client. By closing the client proxy as suggested by Shiraz should fix this.

Juval's book also says this with regard to one-way operations:

If the number queued messages has exceeded the queue's capacity, then the client will block, even when issuing a one-way call. However, one the call is queued, the client is unblocked and can continue executing, while the service processes the operation in the background.

So while one-way operations do allow for fire-and-forget operation, you can still run into cases where your client may block.