Я написалHttpListener который слушает на одном из портов:

httpListener.BeginGetContext(new AsyncCallback(ListenerCallback), httpListener);

ListenerCallback обрабатывает любой запрос, полученный на URI слушателя. Если во время обработки запроса возникает исключение, он запускает диагностическую подпрограмму, которая пытается поразить uri прослушивателя, просто чтобы проверить, действительно ли прослушиватель действительно работает и прослушивает uri, и записывает журнал ответа, возвращенного прослушивателем. Слушатель просто возвращает строкуListening... на такие пустышки.

Теперь во время тестирования, когда в других модулях возникла исключительная ситуация, которая привела к выполнению диагностических модулей, я вижу, что слушатель вернулсяListening... правильно, когда я проверил журналы. Однако, когда исключение произошло вListenerCallback, попытка поразить URI слушателя внутри диагностики вызвала следующее исключение:

System.Net.WebException : The operation has timed out
   at System.Net.HttpWebRequest.GetResponse()
   at MyPackage.Diagnostics.hitListenerUrl(String url) in c:\SW\MyApp\MyProj\Diagnostics.cs:line 190

Эта строка 190 в модуле диагностики выглядит следующим образом:

189     HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
190     HttpWebResponse response = (HttpWebResponse)request.GetResponse();

Сейчас еслиAsyncCallback рассылает новую ветку и запускаетListenerCallback в этой новой теме это не должно приводитьOperation Timeout когда фиктивный запрос отправляется через диагностику. Это то, что я думал, что желаемое поведение должно быть, так как это*Async*Callback, На самом деле MSDN такжеговорит то же самое:

Используйте делегат AsyncCallback для обработки результатов асинхронной операции в отдельном потоке.

Но, похоже, дело не в этом. Я что-то здесь упускаю?

Визуальный перевод: «