Я в тупике? Зачем?

Question

У меня есть приложение Silverlight 3, которому нужно вызвать службу WCF. Служба WCF, в свою очередь, вызывает веб-службу ASMX. По завершении вызова службы WCF пользовательский интерфейс silverlight необходимо обновить.

WCF вызывается в асинхронном режиме.

Дело в том, что приложению Silverlight необходимо вызывать метод WCF (который позже вызывает asmx внутри) сотни раз. Я понимаю, что, поскольку он находится в aSync, будут созданы сотни потоков, поэтому я написал код проверки, чтобы убедиться, что функция WCF вызывается не более, чем за X раз. Только после 1 звонка я могу добавить еще один звонок. Я надеюсь, что это будет контролировать общее количество потоков. Каково идеальное значение этого значения Х? Я на простой машине XP с двухъядерным процессором и 4 ГБ оперативной памяти.

Когда вызовы WCF будут завершены, мне нужно отобразить индикатор выполнения на интерфейсе silverlight.

Это прекрасно работает для меньшего числа вызовов, но когда мне нужно сказать примерно 10000 вызовов, через некоторое время я получаю тайм-аут в методе WCFCompleted Silverlight. Я чувствую, что могу зайти в тупик?

Мой WCF настроен для одновременной работы нескольких пользователей.

Каждый раз, когда завершается один вызов WCF, он обновляет пользовательский интерфейс ... может ли это быть причиной этой тупиковой ситуации?

Есть идеи у кого-нибудь? Я застрял плохо и потерян здесь.

Answer 1

Заслонка возникает только тогда, когда один поток выделяет ресурс и ожидает другого, в то время как другой поток выделяет второй ресурс и ожидает первого. Никто не может продолжать.

Проблема в том, что когда несколько потоков вызывают пользовательский интерфейс Windows, ни один из них не знает о внутренних ресурсах, которые пытается использовать Windows. Невозможно предсказать, каким может быть результат; возможен тупик.

Answer 2

Позже я, казалось бы, решил проблему следующим образом: 1) преобразовал службу asmx в WCF 2) увеличил тайм-ауты WCF с 1 минуты до 5 минут 3) вместо обновления индикатора выполнения интерфейса при каждом обратном вызове Completed я теперь использую таймер, которыйПользователь говорит только каждые 30 секунд.

Answer 3

Я сомневаюсь, что в этом сценарии вы столкнулись с многопоточным тупиком. WPF, и я также уверен, что Silverlight использует потоковый диспетчер для отправки сообщений из рабочих потоков в пользовательский интерфейс. Это одна из причин, почему такие интерфейсы настолько отзывчивы. Более вероятно, что вы перегружаете стек конечной точки WCF, его буферы или конвейерный стек ASP.NET и / или буферы. Когда дело доходит до обработки сетевых подключений, существуют ограничения на то, как быстро и часто вы можете создавать значительное количество подключений. Если вы создаете 10000 подключений в течение пары минут друг от друга, вполне возможно, что вы перегружаете стек TCP. Когда сокет закрыт, он не может быть повторно использован немедленно и переходит в состояние ожидания примерно на 4 минуты. Если вы отключите несколько пакетов по 10 000 соединений в течение 4 минут, вы будете использовать все доступные сокеты, в результате чего WCF (и любые другие приложения Windows за исключением тех, которые имеют зарезервированные порты) не смогут обмениваться данными. Я не уверен, что вы столкнулись с этим (вам действительно нужно использовать лот сокетов), но я подробно ответил на другой вопрос о том, как увеличить пороговые значения по умолчанию стек Windows TCP здесь:

WCF: System.Net.SocketException - обычно допускается только одно использование каждого адреса сокета (протокола / сетевого адреса / порта)

Если вы действительно хотите перейти к сути проблемы, я рекомендую включить ведение журнала трассировки WCF. Журналы трассировки WCF собирают значительное количество информации и предоставляют чрезвычайно подробную информацию о каждом подключении и обработанном сообщении. После включения вы сможете определить проблему, если она не возникает в конвейере ASP.NET или HTTP.sys, даже не достигнув WCF. Я рекомендую прочитать следующие статьи:

• Настройка трассировки
• Настройка регистрации сообщений
• Рекомендуемые настройки для трассировки и ведения журнала сообщений
• Аудит и логирование
• Средство просмотра служебной трассировки (SvcTraceViewer.exe)

Answer 4

Таким образом, сотни потоков не раскручиваются, если вы не делаете это. Смысл асинхронного вызова заключается в том, что вызов сделан, и ничего не существует (так как ничего не может произойти) до тех пор, пока операция не будет завершена и отправлена ​​в порт завершения. Это предполагает, что вы используете обратные вызовы. Если вы вызываете EndXXX для IAsyncResult, поток блокируется до завершения операции.

Теперь может произойти пара вещей. Во-первых, если у вас сложный сервисный бэкэнд, у вас может возникнуть тупик в вашем сервисе. Однако, во-вторых, и, скорее всего, вам нужно настроить конфигурацию службы WCF. Настройка WCF - это черное искусство, когда вы понимаете, что обычно клянетесь, что больше никогда не будете использовать WCF.

Сколько исходящих соединений одновременно разрешено на вашем клиенте и, наоборот, входящих соединений разрешено на вашем сервисе? Использование WCF tracing как на клиенте, так и на сервере - это обычно то, что вам нужно для решения этих типов проблем. Я рекомендую начать там, так как я позволю вам получить подробную информацию, необходимую вам, чтобы увидеть, что на самом деле происходит.