#wcf #msmq #appfabric
#wcf #msmq #appfabric
Вопрос:
У меня есть веб-служба .NET 4.5 WCF, которая использует сообщения из локальной частной очереди MSMQ, запущенной на Windows Server 2008 R2 с установленным AppFabric.
Эта служба считывает сообщения из очереди и обрабатывает файлы, на которые ссылаются в сообщении, я использовал AppFabric, чтобы отключить службу для обработки 16 одновременных сообщений, по 8 для каждого рабочего процесса AppPool.
AppPool использует учетную запись домена, которая имеет полные права доступа к общему сетевому ресурсу, где хранятся файлы, подлежащие обработке.
Эта служба работала нормально в течение многих лет, за исключением того, что на прошлой неделе ~ 90% файлов, которые ее просили обработать, завершились с ошибкой либо с UnauthorizedAccessException.
Это поведение проявлялось во всех службах на этом сервере приложений, независимо от того, с какого файлового сервера службе было предложено обработать файлы. Даже файлы, которые ранее обрабатывали file, теперь терпели неудачу.
Комментарии:
1. У меня есть очень интересный ответ, но, видимо, я не могу опубликовать его в течение 8 часов, извиняюсь, если у вас такая же проблема.
2. Нет, я имел в виду, что кто-то отклонил ваш вопрос, не оставив комментария, что довольно грубо. Тем не менее, я поддержал ваш вопрос, оставив вас с чистой оценкой вопроса 0. С нетерпением жду вашего ответа.
3. Возможно, голосование против было вызвано тем, что заголовок описывает основную проблему, а не описанные симптомы, я думаю, мы никогда не узнаем
Ответ №1:
После долгих бесплодных выходных поисков и взлома различных вещей, в том числе:
- Разрешения и квоты для общих папок
- Лицензирование Windows (CAL и т. Д.)
- Брандмауэры
- Различные исправления программного обеспечения для веб-приложения
В конце концов я случайно обнаружил фактическую проблему, при повторном развертывании веб-приложения я заметил что-то странное. Когда я остановил веб-приложение через меню WCF в IIS, сообщения продолжали использоваться, поэтому я остановил остановленный пул приложений, запускающий веб-службу, но сообщения продолжают использоваться, хотя это может быть связано с большой задержкой, добавленной к состоянию сообщения MQMQ службой распределенных транзакцийкогда много сообщений откатывается в очередь сообщений с ядом, я пошел на обед. Когда я вернулся, сообщения все еще использовались, и process Explorer подтвердил, что apppool, на котором работает мой сервер, больше не выполняется.
Что-то явно произошло, но было неясно, является ли это причиной, симптомом или совпадением. Решающим моментом было то, что когда я снова отрегулировал свою службу, чтобы обрабатывать только одно сообщение за раз, чтобы проверить, достигает ли доступ к общему ресурсу какого-то предела, я заметил, что частота отказов выросла до ~ 98%. Это наводило на мысль, что что-то еще обрабатывало сообщения и давало сбой, но также сообщало об этих сбоях в мою систему отчетов способом, доступным только моему приложению.
Небольшое дальнейшее расследование показало, что пул приложений по умолчанию, используемый для обслуживания веб-сайта по умолчанию, также выполнял мою веб-службу WCF, но не смог получить доступ к файлам на файловом сервере, поскольку идентификатор, используемый для запуска пула приложений по умолчанию, не имел привилегий. сбои заняли меньше времени, чем успешные файловые процессы для этогочем медленнее я запускал свою службу, тем больше сообщений было сброшено пулом приложений по умолчанию.
Причина
Пока я регулировал регулирование в своем веб-приложении, я случайно установил регулирование или веб-сайт по умолчанию, который был родительским для веб-приложения, я заметил, что это отклоняется, и сбросил их обратно к значению по умолчанию. В то время я не осознавал, что это добавило <system.servicemodel> тег в веб-конфигурацию веб-сайта по умолчанию. Результатом этого стало то, что мой веб-сайт по умолчанию начал вести себя как веб-приложение, и по причинам, которые мне еще предстоит понять, он начал выполнять функциональность своего дочернего веб-приложения, это может быть связано с активацией WAS, все, что я знаю, это то, что я, безусловно, не желал поведения.
Исправление
Я удалил <system.servicemodel> тег и его содержимое с web.conf веб-сайта по умолчанию и удалил net.msmq из списка включенных протоколов, и все вернулось к нормальной жизни.