none
NetNamedPipeBinding: The pipe could not close gracefully.

    Question

  • Hi,

     

    I repeatedly get the following error in my wcf trace logs:

     

    The pipe could not close gracefully.  This may be caused by the application on the other end of the pipe exiting.

     

    as well as:

     

    There was an error writing to the pipe: Unrecognized error 232 (0xe8).

     

     

    We do not get any other exceptions in the wcf logs, and it seems that these errors do not cause any application level exceptions, so I assume that this works on a retry basis. This means that we are currently experiencing out of band, Wcf plumbling level eceptions which aren't fatal. Unfortunately, I have to find out why this is happening, because it's filling up the logs and it's affecting the .net exceptions performance counter.

     

    The services are on the same machine, that's why we are using netNamedPipe bindings. Here follows the binding configuration on the server and client side:

     

    <netNamedPipeBinding>

    <binding name="default"

    maxConnections="1500"

    maxReceivedMessageSize="99999998"

    receiveTimeout="00:10:00"

    transactionFlow="false">

    <readerQuotas maxDepth="96" maxStringContentLength="9000000" maxBytesPerRead="9000000"/>

    <security mode="None">

    </security>

    </binding>

    </netNamedPipeBinding>

    Tuesday, November 27, 2007 4:16 PM

Answers

  • Can you include your full stack trace? In general this usually occurs when an idle pipe is being closed from our client connection pool, but the server side has already timed out. Another case this occurs is when the server initiates a graceful close, the client isn't listening (with a pending receive or Close), and so the server Close times out. I suspect that you are missing a call to channel.Close() in one of your client paths.

    Tuesday, December 11, 2007 6:04 PM

All replies

  • It usually means the client closed or died before the server returns. The error is from the server attempting to return to a closed pipe.

    What is the client?
    Tuesday, November 27, 2007 4:26 PM
  • The answer is not simple, I'm afraid. We currently have an SOA architecture with services talking to each other. We also have an intermediary service which routes all the calls between the consumers and target services.

     

    I'm seeing these errors in the first target service as well as the intermediary, but it's diffcult to see whether it's actually when it's acting as a service or a client when it experiences the error. It seems from the logs that it alternates between the pipe could not close and unrecognized error exceptions. So I can probably assume that the pipe could not close exception is when the service is being consumed and that the unrecognized error is when it is trying to consume something itself.

     

    Maybe the problem is due to the chaining of the service calls itself? Meaning, Service A calls intermediary, intermediary calls Service B. Service B calls the intermediary, intermediary calls Service C.

     

    Can this be due to the proxy being disposed before being expclitly closed? We have our proxies wrapped in a using statement which calls dispose. Should we rather do an explicit close on the proxy objects?

     

    Thanks

    Hendrik

    Tuesday, November 27, 2007 4:52 PM
  • Close() should be called by any Dispose() call. This could happen though if the proxy is disposed or closed before the service returns. Is that happening?


    Tuesday, November 27, 2007 5:28 PM
  • No, all the logic succeeds successfuly. We are running a stress testing tool against the website which communicates with the services layer and all the instances finish successfully. There are no application exceptions being logged, which would happen if the client could not get a response from a service.

    There are also no other exceptions in the wcf traces than these entries...

    Tuesday, November 27, 2007 6:47 PM
  • Interesting. I saw this also when using an error handler behavior (IErrorHandler) when an exception was being thrown that wasn't in the fault contract.

    I can force this error when debugging - just allow the client to time out and have the server debugging - run through and complete the method on the service...it completes but the WCF runtime logs the can't write to pipe error.

    I'll let you know if I think of anything else. I ran through finding the cause of my errors months ago and it ended up being the error handler...but I don't think yours has anything to do with this.
    Tuesday, November 27, 2007 6:58 PM
  • Can you include your full stack trace? In general this usually occurs when an idle pipe is being closed from our client connection pool, but the server side has already timed out. Another case this occurs is when the server initiates a graceful close, the client isn't listening (with a pending receive or Close), and so the server Close times out. I suspect that you are missing a call to channel.Close() in one of your client paths.

    Tuesday, December 11, 2007 6:04 PM