WCF Асинхронный тупик? - PullRequest
Новая
       35

WCF Асинхронный тупик?

1 голос
/ 16 июня 2011

Кто-нибудь сталкивался с ситуацией, когда вызов WaitAny возвращает действительный индекс дескриптора, но блокирует вызов Proxy.End?Или есть какие-либо рекомендации или как лучше отладить это - пробная трассировка, счетчики производительности (для проверки максимального процента), ведение журнала везде

Сценарий тестирования: 2 асинхронных.запросы уходят (есть еще немного к полной реализации), и 1-й вызов Proxy.End успешно возвращается, но последующие блоки.Я проверил след WCF и не вижу ничего особенно интересного.ОБРАТИТЕ ВНИМАНИЕ, что он сам запрашивает конечную точку, которая существует в том же процессе, что и на удаленном компьютере (= 2 асинхронных запроса)

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

Я пробовал разные "concurrencymode" и "instancecontextmode", но, похоже, это не имеет никакого отношения к результату.

Вот урезанная версия внутреннего кода для анализа списка дескрипторов: 

ValidationResults IValidationService.EndValidate()
    {
        var results = new ValidationResults();

        if (_asyncResults.RemainingWaitHandles == null)
        {
            results.ReturnCode = AsyncResultEnum.NoMoreRequests;
            return results;                
        }

        var waitArray = _asyncResults.RemainingWaitHandles.ToArray();
        if (waitArray.GetLength(0) > 0)
        {
            int handleIndex = WaitHandle.WaitAny(waitArray, _defaultTimeOut);
            if (handleIndex == WaitHandle.WaitTimeout)
            {
                // Timeout on signal for all handles occurred                    
                // Close proxies and return...
            }

            var asyncResult = _asyncResults.Results[handleIndex];



            results.Results = asyncResult.Proxy.EndServerValidateGroups(asyncResult.AsyncResult);

            asyncResult.Proxy.Close();
            _asyncResults.Results.RemoveAt(handleIndex);
            _asyncResults.RemainingWaitHandles.RemoveAt(handleIndex);

    results.ReturnCode = AsyncResultEnum.Success;
            return results;
        }

    results.ReturnCode = AsyncResultEnum.NoMoreRequests;
        return results;
    }

и код, который вызывает это: 

 validateResult = validationService.EndValidateSuppression();
 while (validateResult.ReturnCode == AsyncResultEnum.Success)
 {
       // Update progress step                        
       //duplexContextChannel.ValidateGroupCallback(progressInfo);

     validateResult = validationService.EndValidateSuppression();
 }

У меня естьзакомментировал обратные вызовы на инициирующем узле (к вашему сведению, это фактически 3-уровневая установка, но проблема изолирована от этого 2-го уровня, вызывающего 3-й уровень - обратные вызовы переходят со 2-го уровня на 1-й уровень, которые были удалены в этом тесте).Мысли

1 Ответ

0 голосов
/ 29 июня 2011

Придерживаясь решения, я оставил в своем комментарии.Просто избегайте связывания обратного вызова с вызовами aysnc, которые имеют разные пункты назначения (например, прокси)

...