WCF тайм-аут не соблюдается

Question

Я новичок в проекте, который широко использует WCF, и мой опыт работы с WCF не является обширным. Я пытаюсь отследить проблему, когда мой пользовательский интерфейс представляет ошибку тайм-аута через 10 минут, ожидая возврата долговременного вызова службы. Грубо вот что мой проект предполагает:

[service A] <=> [service B] <=> [UI console] 

И вот что я подбирала thusfar:

• таймаут происходит между serviceA и serviceB, а не между serviceB и консоли пользовательского интерфейса, потому что я на самом деле есть две отдельные консоли пользовательского интерфейса: одна представляет собой оснастку MMC, а одна - оснастку PowerShell, и оба имеют тот же самый 10-минутный тайм-аут.

• Мои конечные точки как в обслуживании, так и в обслуживанииB использование basicHttpBinding; оба имеют bindingConfigurations, которые определяют sendTimeout и receiveTimeout через 30 минут, а не 10 минут.

• ReliableSession.InactivityTimeout по умолчанию 10 минут. Я прочитал, но я не считаю, что это ReliableSession, поэтому он не применяется.

• I приборное обслуживаниеB для трассировки WCF; ServiceTraceViewer показал соответствующую активность до начала долговременного вызова службы, после чего ничего не доходило до 10 минутного тайм-аута.

Не стесняйтесь оспаривать меня по любому из моих утверждений и/или дайте мне знать, что еще я могу сделать, чтобы диагностировать эту проблему.

2013.04.04 Обновление

Вот реальное сообщение об ошибке:

канал запроса истекло время ожидания ответа после 00: 09: 59.9839984. Увеличьте значение тайм-аута, переданного на вызов, Запросите или увеличьте значение SendTimeout в Binding. Время , выделенное этой операции, могло быть частью более длинного времени ожидания .

сервера трассировки стека: в System.ServiceModel.Channels.RequestChannel.Request (сообщение Message, TimeSpan тайм-аут) в System.ServiceModel.Dispatcher.RequestChannelBinder.Request (Message сообщение, TimeSpan тайм-аут) в системе. ServiceModel.Channels.ServiceChannel.Call (действие Строка, Логическое односторонняя, операция ProxyOperationRuntime, Object [] модули, Object [] выходы, TimeSpan тайм-аут) при System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (операция IMethodCallMessage methodCall, ProxyOperationRuntime) в System.ServiceModel.Channels.ServiceChannelProxy.Invo ка (Шеззаде сообщения)

Исключения при вызвана повторно [0]: в System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (Шеззаде reqMsg, Шеззаде retMsg) в System.Runtime.Remoting.Proxies.RealProxy. PrivateInvoke (MessageData & msgData, Int32 type) в NextIT.ActiveAdministration.DataContracts.IActiveAdministration.PublishAgentSettings() на ...

И внутреннее исключение:

Запрос HTTP на 'http://localhost/MyAdminService/' превысил отпущенное таймаут 00:10:00. Время, отведенное на , могло быть частью более длительного таймаута.

на System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException (WebException WebException, HttpWebRequest запрос, HttpAbortReason abortReason)
на System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply (TimeSpan тайм-аут) в System.ServiceModel.Channels.RequestChannel.Request (сообщение Message, TimeSpan таймаута)

Answer 1

Существует старая пословица «Если она не работает, попробуйте подключить ее». Я был настолько сосредоточен на том, чтобы прокладывать себе путь через мучительные завихрения и повороты файла app.config, изобилующего пожаром и чреватым путаницей - отчасти потому, что на самом деле есть 5 файлов app.config с множеством привязок и сервисов в этом большом проект - что я не заметил очевидную часть, где код был переопределяем конфигурационный файл (!):

binding.ReceiveTimeout = new TimeSpan(0, 0, 10, 0); 
binding.SendTimeout = new TimeSpan(0, 0, 10, 0); 

Вздох.

Но подождите - больше. Сначала я почесывал голову, почему 30-минутное значение из файла конфигурации не повлияло, потому что таймаут произошел через 10 минут? Ну, оказывается, что 10-минутный тайм-аут, установленный в коде, как показано выше, был от консоли UI до serviceB. 30-минутный тайм-аут, установленный в конфигурационном файле, был от службы Б до serviceA, поэтому мне пришлось открыть как для, так и для продолжительной работы.

Answer 2

Try играть с операции тайм-аут, как описано здесь: http://final-proj.blogspot.co.il/2009/09/wcf-timeouts.html?m=1

Также такая конфигурация служб может вызвать таймаут, например, работу с обратными вызовами. , , (из этого поста Timeouts WCF Services)