Я использую netNamedPipeBinding, и мои методы обслуживания ничего не возвращают (void), но время ожидания истекло:
TimeoutException: «Операция открытия не завершилась в течение выделенного времени ожидания 00:01:00. Время, отведенное для этой операции, могло быть частью более длительного времени ожидания».
Трассировка стека серверов:
в System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (время ожидания TimeSpan)
в System.ServiceModel.Channels.CommunicationObject.Open (время ожидания TimeSpan)
в System.ServiceModel.Channels.ServiceChannel.OnOpen (время ожидания TimeSpan)
в System.ServiceModel.Channels.CommunicationObject.Open (время ожидания TimeSpan)
в System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (время ожидания, каскад CallOnceManager)
в System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan timeout)
в System.ServiceModel.Channels.ServiceChannel.Call (действие String, логический односторонний режим, операция ProxyOperationRuntime, Object [] ins, Object [] outs, TimeSpan timeout)
в System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (метод IMethodCallMessageCall, операция ProxyOperationRuntime)
в System.ServiceModel.Channels.ServiceChannelProxy.Invoke (сообщение IMessage)
Исключение переброшено в [0]:
в System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg)
в System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & msgData, тип Int32)
Чтобы избежать этого, я превратил свой сервис в OneWay операцию. Но тайм-аут все еще происходит. Я ожидал, что это решило мою проблему. Является ли netMsmqBinding единственным, кто мог бы избежать такого тайм-аута?
Я также попытался выполнить всю обработку в отдельном потоке, чтобы служба могла отключиться раньше, но безуспешно.