Я унаследовал это огромное приложение, состоящее из кода клиента и сервера, и я пытаюсь изменить режим передачи части нашего сообщения на «потоковое», чтобы обойти действительно расточительное потребление памяти, которое может происходят в буферизованном режиме и заставляет мой клиент отбрасывать исключения OOM, см. также this answer.TimeoutException when TransferMode = Streamed
код выглядит примерно так:
GZipMessageEncodingBindingElement gElement = new GZipMessageEncodingBindingElement();
HttpsTransportBindingElement hElement = new HttpsTransportBindingElement();
hElement.TransferMode = TransferMode.Streamed;
hElement.MaxBufferSize = int.MaxValue;
hElement.MaxBufferPoolSize = int.MaxValue;
hElement.MaxReceivedMessageSize = int.MaxValue;
CustomBinding binding = new CustomBinding();
binding.SendTimeout = new TimeSpan(0, 0, 60);
binding.Elements.Add(gElement);
binding.Elements.Add(hElement);
EndpointAddress address = new EndpointAddress(uri);
return new ChannelFactory<T>(binding, address).CreateChannel();
И исключение составляет TimeoutException, что предполагает я увеличить SendTimeout (который в настоящее время устанавливается на 1 минуту).
Update: Однако, есть 2 услуги, которые все еще работают после установки transferMode в потоковом, я на самом деле подтвердили, что они используют GZIP/HTTPS, установив контрольные точки в GZIPMessageEncoder.ReadMessage (Stream, ...). Таким образом, для 2 сервисов он ломается внутри ReadMessage, для одной службы это не так. Насколько я могу судить, службы настроены одинаково, когда дело доходит до ConcurrencyMode и InstanceContextMode.
Обновление 2: После настройки только одной службы, которая, похоже, не работает как потоковая передача, а остальные 2 службы буферизованы, она отчасти работает. Таким образом, это не тот сервис, который является плохим, возможно, какое-то соединение мешает другим соединениям в потоковом режиме, что делает их тайм-аутом.
Если я удалю только строку «TransferMode», все будет в порядке, и тестовому серверу не потребуется больше секунды или около того, чтобы ответить, поэтому просто увеличение SendTimeout никуда не приведет.
Для этого теста я только изменил клиентский ответ. Насколько мне известно, этот параметр не должен влиять на взаимодействие клиента и сервера, как то, как приложение с «потоковым» параметром обрабатывает данные.
Пожалуйста, будьте лёгкой, я полный WCF newb, и хотя я видел некоторые оговорки на страницах MSDN о потоковом режиме передачи, указатель на то, что для grep для моего кода/конфигурации будет действительно полезно, в противном случае это просто огромная, много услуг, каждая с различными транспортными настройками и т. д.
Спасибо!