none
Always get TimeoutException when closing NetNamedPipe communication channel (whatever the Timeout value i set) RRS feed

  • Question

  • I create a new channel for every operation call and attempt to close it immediately after the call completes.

    I keep getting TimeoutExceptions in my ICommunicationObject.Close() call whatever the actual value of the timeout.

    I can set it to 5 days and i am certain it would block for 5 days waiting to close that channel.

    I have tried NamedPipes and NetTcp and they both have the same issue. When i use BasicHttp though everything works! I do not want to use Basic though.

    Any ideas?


    Monday, September 15, 2014 7:54 PM

Answers

  • The issue occurs because my ServiceHosts post work on the UIThread and when both try to talk to each other then they deadlock.
    Friday, September 19, 2014 5:11 PM

All replies

  • Hi,

    TimeoutException occurs when the default close timeout elapsed before the ICommunicationObject was able to close gracefully.

    If the default close timeout elapses before the ICommunicationObject is able to close gracefully, the ICommunicationObject is aborted.

    If Close is called on an ICommunicationObject in the Created, Opening, or Faulted state, the ICommunicationObject is aborted. If Close is called on an ICommunicationObject in the Closing or Closed state, the call returns immediately.

    For more information, you could refer to:

    http://www.codeproject.com/Tips/197531/Do-not-use-using-for-WCF-Clients

    http://stackoverflow.com/questions/530731/how-to-make-sure-you-dont-get-wcf-faulted-state-exception

    Regards

    Tuesday, September 16, 2014 8:25 AM
    Moderator
  • This answer doesn't help.

    Tuesday, September 16, 2014 3:21 PM
  • Basically, the timeoutexception indicates that this request operation sent to net.tcp://localhost:4001/ ClsWCFImpl did not receive a reply within the configured timeout (00:01:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.

    About Timeouts in WCF, you could refer to:

    http://blogs.msdn.com/b/hongmeig/archive/2010/03/06/timeouts-in-wcf-and-their-default-values.aspx

    http://www.codeproject.com/Articles/62934/Many-to-One-Local-IPC-using-WCF-and-NetNamedPipeBi

    http://www.codeproject.com/Articles/28265/WCF-Operation-Timeout-Exception

    Wednesday, September 17, 2014 2:33 AM
  • Some more info.

    I am using NamedPipes for interprocess communication.

    Every process listens to a unique named pipe.

    When 2 processes try to talk to each other simultaneously (on their respective pipes of course) i keep getting TimeoutExceptions or the calls get blocked and result in CommunicationObjectFaulted.

    If i use Dispatcher.BeginInvoke() to queue up the calls then it works fine but i should not have to do this since every process has its own pipe!

    Surely process 1 can send a message to process 2 on pipe 2 at the same time as process 2 sends process 1 a message on pipe 1 right??

    Wednesday, September 17, 2014 7:59 AM
  • The issue occurs because my ServiceHosts post work on the UIThread and when both try to talk to each other then they deadlock.
    Friday, September 19, 2014 5:11 PM