none
net.pipe binding under IIS, the endpoint is lost after IIS cycles the application RRS feed

  • Question

  • This problem was initially reported by our performance test team which uses Windows Server 2008 R2; I was able to reproduce on a Windows 7 64 bit machine. I believe what I describe below applies to Windows Server 2008 R2 as well. 

    My test environment is quite simple:

    • Service: hosted under IIS with both HTTP and net.pipe endpoints. 
    • Client: the client keeps calling the service in a tight loop over net.pipe binding.

    While the client is making the call, I update web.config from time to time which would force the IIS application to cycle.

    The following can be observed after the web.config file is updated a few times:

    • The client gets CommunicationException with message "There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).".
    • The client then immediately retries the call by acquiring a new channel. (this logic is built into client code to recover from faulted channel)  
    • The client then (most of the time) gets Timedout Exception for the retry.
    • The net.pipe endpoint appears to have stopped working after that, rerunning the client would always get TimedoutException.
      However, the HTTP endpoint still returns calls in the meantime.
    • Updating web.config file cannot bring the net.pipe endpoint back. Only “iisreset” can bring net.pipe endpoint to a working state.

    This behavior seems to indicate some sort of bug in WCF. Have anyone seen it before? 



    • Edited by Wenning Qiu Thursday, August 1, 2013 3:07 PM
    Thursday, August 1, 2013 3:06 PM

All replies

  • I did some more tests with BasicHttpBinding and NetTcpBinding.

    HTTP binding is the smoothest: the client side does not get any CommunicationException and no loss of the endpoint.

    Similar problem exists for Net.Tcp binding; the difference is only the message text of CommunicationException: “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. …”. 

    For Net.Tcp and Net.Pipe bindings, the loss of an endpoint only happens when the web.config file is frequently updated while the service is having active connections.

    The loss of one endpoint does not affect other endpoints using different bindings. IIS appears to continue responding to web.config changes by cycling the application AppDomain, but the lost endpoint won’t comeback until the IIS application pool is cycled(or iisreset).

    Thursday, August 1, 2013 9:14 PM
  • Hi,

    By default, IIS supports http or https protocols, so the binding like netTcpBinding or netNamedPipeBindings can not be used in IIS host.

    For more information, please try to refer to:
    http://everythingms.wordpress.com/2012/03/12/running-tcp-and-named-pipes-wcf-services-on-iis-7-x/ .

    Then if we want to use netTcpBindings or netNamedPipeBinding, we need to manage some settings.

    Here is a artilce about this, please try to check:

    #Hosting WCF service with netTcpBinding or netNamedPipeBinding in IIS:
    http://dotnetmentors.com/hosting-wcf-service-with-nettcpbinding-or-netnamedpipebinding-in-iis.aspx .

    Best Regards.


    Amy Peng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Friday, August 2, 2013 9:25 AM
    Moderator
  • Thanks Amy for your response. 

    I have no problem getting WCF services hosted under IIS using net.tcp binding and net.pipe binding. The two questions that I have are:

    1) When web.config file is updated, why active connections using net.tcp and net.pipe bindings may get CommunitationException, while the connections using http binding don't.

    2) When web.config file is updated, why net.tcp and net.pipe endpoints may become unreachable until the IIS application pool is cycled.

    Details are in my original posts. 

    Monday, August 5, 2013 2:34 PM
  • Hi Wenning,

    As you've already known, when the web.config file (or the priviate bin dir) is modified, the ASP.NET application (appdomain) will be restarted. This will cause the original WCF service instanced by terminated until the future requests trigger the new instance (after new application appdomain starts) to be activated.

    For the behavior you found (HTTP and TCP(or namped pipe) binding has different connection behavior during restart period), I think it might be related to transport protocol they physically rely on. When you update the web.config and try accessing the WCF service again, are you still using the original created client proxy (in client application) or create new WCF client proxy? For binding like basicHttpBinding, since it is based on statuless HTTP protocol and is not session oriented, it should be ok no matter the service has restarted or not. However, for netTcpBinding and named pipe binding, they are based on tcp and named pipe transport protocol which is naturally connection/session oriented. So if the server-side service (and original connection) be lost, the original client proxy (which already established the connection to server) will completely loose the connection and we need to create a new proxy to access the service again. 


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, August 8, 2013 8:15 AM
    Moderator
  • Thanks for your response Steven. I agree with your explanation why BasicHttpBinding and Net.Tcp/Net.Pipe bindings behave differently. 

    I apologize the original questions that I posted are vague; at the time I noticed some problems in the testing but was not sure about what the real issues are.

    After further testing, I was able to identify two issues with services hosted under IIS using net.tcp and net.pipe bindings. I have opened two support tickets with Microsoft and demoed the problems to the support engineers. 

    For those interested, below are what I sent to Microsoft.

    Problem One

    Environment:

    • WCF service hosted under IIS using net.tcp or net.pipe bindings.
    • Windows 7 x64, Windows Server 2008 R2.

    Steps to recreate:

    • A client continuously calls the service.
    • Update the web.config file to cause IIS to cycle the service AppDomain.
    • The client gets CommunicationException about 10 seconds after the update as the service AppDomain is cycled.
    • The client sees the channel being faulted by the CommunicationException, so it reconnects to the service and retry the call.

    Problem:

    We found that sometimes the same request data are used to call the service more than once. It appears that when the service sends a CommunicationException to the client, the service could be in any stage in processing a call; for example:

    1. The service has not received the request data yet.
    2. The service has received the request but has not started processing yet.
    3. The service has received the request and completed processing but has not sent the response back to the client yet.

    So if the service is in scenario 3), and the client retries the call on CommunicationException, the same request data is used more than once to call the service.

    Note that the same problem exists when IIS application pool is recycled(e.g. periodical recycled every certain number of minutes).


    Questions:

    • As a client, how do I tell for sure what happens to my call when a channel is faulted by a CommunicationChannel?
    • As a server, can I tell that a response wasn't delivered to a client?

    Problem Two

    Environment:

    • WCF service hosted under IIS using net.tcp or net.pipe bindings.
    • Windows 7 x64, Windows Server 2008 R2.

    Steps to recreate:

    • The client continuously calls the service while the web.config file is updated.
    • The client gets CommunicationException after about 10 seconds, the client then immediately retries the call by acquiring a new channel.
    • At the same time I update the web.config a few more times. 
    • The client then (most of the time) gets TimedoutException for the retry.
    • The net.tcp/net.pipe endpoint appears to become unreachable after that. Subsequent execution of the client would always get TimedoutException. However, other endpoints on the same service still returns calls in the meantime, and IIS appears to continue responding to web.config changes by cycling the application AppDomain(observed from the working endpoints).
    • The lost net.tcp/net.pipe endpoint remains unresponsive. Only cycling the IIS application pool can bring net.tcp/net.pipe endpoint to a working state.

    BasicHttp binding does not have such issue.

    Question:

    Is there any unsafe code in WCF in handling the interaction of active connections and service AppDomain cycling?

    • Edited by Wenning Qiu Thursday, August 8, 2013 10:10 PM
    Thursday, August 8, 2013 10:01 PM
  • Hi ,

    How can I create a new proxy? I am facing same issue with namped pipe.

    Friday, October 17, 2014 1:16 PM