Asp.net Web API self host service необработанное исключение при удалении клиента при подключении

Question

Я использую web api сам хост внутри службы Windows, и я столкнулся с проблемой, и после того, как поисковая система в течение нескольких часов не нашла разумный ответ.

Один из контроллеров api обслуживает большой поток данных (не очень большой, пара десятков МБ). Для получения данных требуется некоторое время, поэтому я решил использовать TransferMode.StreamedResponse, чтобы минимизировать время, в течение которого клиент должен ждать ответа. Я также добавил CompressHandler и пользовательский CompressedContent (производный от HttpContent) в основном на основе следующих answer.

Контроллер возвращает экземпляр IDataReader, который затем сериализуется пользовательским форматированием, который в конечном итоге сжат внутри CompressedContent, о котором я упомянул. Весь проход данных равен потоковым, поэтому, пока клиент получает данные, устройство чтения данных на стороне сервера все еще может считывать строки из базы данных. Все работает нормально, когда клиент действует красиво.

Проблема возникает, когда клиент отключает подключение, пока данные все еще сериализуются в базовый сетевой поток. Я попытался наблюдать за задачей IsFaulted внутри ContinueWith делегировать (в CompressedContent из ссылки) и уничтожить базовую сеть Stream. К сожалению, CommunicationException (указанное сетевое имя больше не доступно) все еще бросается, когда элемент управления покидает мой код. Из stacktrace похоже, что исключение возникает, когда Web Api пытается закрыть (завершить) базовый сетевой поток (http-канал?). Как это происходит с незаметными исключениями, он приводит к отключению всего окна.

Я смягчил эту проблему, установив параметры восстановления служб Windows, но хотел бы знать, может ли этот отказ обрабатываться в коде.

Есть ли способ настроить собственный обработчик ошибок (IErrorHandler предположительно) внутри веб-сервиса api self hosting, чтобы предотвратить такую ​​ошибку?

Я использую бета-версию, я попытаюсь воспроизвести эту ошибку на RC, но я как-то сомневаюсь, что создание такого рода обработчик ошибок изменится в любом случае

Answer 1

Мы имели один и тот же вопрос. Я смог отправить исправление в MS, и они, в свою очередь, выпустили ночную сборку, которая исправляет это. Они смотрят назад, перенося исправление в RTM. Вы можете увидеть выталкивающий релиз здесь: http://aspnetwebstack.codeplex.com/SourceControl/network/forks/rdean79/issue284/contribution/3329