Клиент WCF зависает при ответе - PullRequest
3 голосов
/ 20 мая 2010

У меня есть клиент WCF (работает на Win7), указывающий на службу WebSphere.

Все хорошо от тестового жгута (маленькое тестовое устройство вне моего веб-приложения), но когда мои вызовы службы исходят из моего веб-проекта, один из вызовов (и только этот) крайне медленно десериализуется минут против секунд) и не только в первый раз .

Я вижу из fiddler, что ответ возвращается быстро, но затем клиент WCF зависает над самим ответом более минуты до того, как отладчик ударит следующую строку кода, почти клиент имел проблемы с десериализацией. Это происходит, только если в ответе у меня есть заданная строка pdf (операция генерирует pdf), закодированная в base64. Например, если служба выдает ошибку (таким образом, pdf-строки нет), ответ немедленно десериализуется.

Опять же, если я отправлю тот же конверт через Soap-UI или извне веб-проекта, все будет хорошо.

Я в растерянности - что мне нужно искать, и есть ли какие-то настройки конфигурации, которые могут помочь?

Любая помощь приветствуется!

EDIT

Я закодировал заглушку для того же контракта на обслуживание. При использовании точно такой же basicHttpBinding и при возврате точно такой же pdf-строки задержка не регистрируется. Я думаю, что это исключает строку и привязку в качестве возможной причины. Что осталось?

Ответы [ 7 ]

3 голосов
/ 26 мая 2010

Изменение transferMode="Buffered" в transferMode="Streamed" на привязке сделало свое дело!

Таким образом, полезная нагрузка, очевидно, разбивалась на маленькие биты размером с буфер.

Я думал, что того же можно было бы достичь, увеличив размер буфера (maxBufferSize="1000000"), но у меня уже было это, и это не помогло.

1 голос
/ 20 августа 2010

У меня была та же проблема ... Проблема WCF, IMO, заключается в десериализации строки base64, возвращаемой службой, на стороне клиента byte [].

Самый простой способ решить эту проблему, если вы не можете изменить конфигурацию службы (например, использовать TransferMode = "Streamed"), - это адаптировать свою сторону клиента DataContract / ServiceContract. Замените тип «byte []» на «string» в ответном DataContract.

Далее просто декодируйте возвращенную строку самостоятельно с помощью фрагмента кода, такого как:

byte [] file = Convert.FromBase64String (pdfBase64String);

Чтобы скачать PDF размером 70 КБ, раньше требовалось ~ 6 сек. С предложенным изменением здесь выше, теперь требуется <1 сек. </p>

V.

PS .: Что касается режима передачи, я пытался изменить только сторону клиента (TransferMode = "StreamedResponse"), но без улучшения ...

1 голос
/ 26 мая 2010

Две вещи, которые вы можете попробовать:

  1. Настройте параметры считывателя для вашего клиента. Смотри http://msdn.microsoft.com/en-us/library/ms731325.aspx

  2. Отключить «Просто мой код» в опциях отладки. Сервис -> Параметры -> Отладка -> Общие «Включить только мой код (только для управляемого)» и посмотреть, сможете ли вы перехватить внутренние исключения WCF.

// huusom

1 голос
/ 23 мая 2010

Если советы других пользователей не помогают, возможно, вы захотите Включить отслеживание WCF и открыть его в Средстве просмотра трассировки . Информация подробная, но она позволила мне решить ряд трудных для идентификации проблем в прошлом.

Более подробную информацию о трассировке WCF можно найти в MSDN .

1 голос
/ 20 мая 2010

Я много раз это кусал. Проверьте в конфигурации клиента WCF, что вы не пытаетесь использовать веб-прокси Windows, этот шаг проверки прокси-сервера (даже если он не настроен) потребует много времени при подключении.

0 голосов
/ 25 мая 2010

Может быть, клиентская сторона пытается проанализировать, какой тип контента поступает со стороны сервера? Попробуйте явно указать тип MIME ответа службы на стороне сервера, например, Response.ContentType = "application/pdf" РЕДАКТИРОВАТЬ: под клиентской стороны я имею в виду любого возможного посредника, как брандмауэр или пакет безопасности.

0 голосов
/ 23 мая 2010

Первые вещи, которые нужно проверить:

  • Является ли конфиг одинаковым в веб-проекте и тестовом проекте?
  • Когда вы тестируете из SOAP UI, вы делаете это с того же сервера и в том же контексте безопасности, что и при запуске кода из веб-проекта. -Есть ли всплеск в памяти, когда PDF возвращается?

Редактировать

Из ваших комментариев появляется 1-минутное ожидание, которое ожидает ожидания. Вы также упоминаете транзакции.

Мне интересно, если проблема в другом месте. Вызов службы WCF идет нормально, но вызов находится внутри транзакции, и транзакция не завершена или не завершена (я предполагаю, что здесь), тогда транзакция / код будет зависать в течение 1 минуты, пока ожидает время ожидания.

Редактировать 2

Следующие вещи для проверки:

  • Есть ли разница в коде теста и в веб-проекте о том, как вызывается сервис.
  • Есть ли разница в версии фреймворка, например, один 3.0, а другой 3.5
...