WCF прекращает отвечать приблизительно после приблизительно 10 вызовов (регулировка)

У меня есть Сервис WCF и приложение с Сервисной Ссылкой на него, и с приложением у меня есть цикл, и в каждом повторении это звонит методу в этом wcf веб-сервисе.

Проблема состоит в том, что приблизительно после приблизительно 9 вызовов, это просто останавливается... и если Вы совершаете нападки Pause кнопка VS, Вы будете видеть, что это застревает на строке, где это выполняет вызов.

Через какое-то время ожидая его, этот TimeoutException брошен:

Канал запроса, приведенный к таймауту при ожидании ответа после 0:00:59.9970000. Увеличьте значение тайм-аута, переданное вызову, чтобы Запросить или увеличить значение SendTimeout на Привязке. Время, выделенное этой операции, возможно, было частью более долгого тайм-аута.


Я исследовал немного на этом и нашел некоторые решения, которые вовлекли редактирование app.config в приложение и здесь являются выборками его:

<serviceBehaviors>
    <behavior name="ThrottlingIssue">
        <serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
    </behavior>
</serviceBehaviors>

.

<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
 maxArrayLength="2147483647" 
 maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" /> 

Затем после того, как я прекращаю отлаживать, после нескольких минут сообщение об ошибке открывается, говоря мне, что Катастрофический отказ произошел.

Как я могу решить эту проблему? У меня не было этой проблемы, когда я работал с нормальным веб-сервисом.


Для ссылки вот целое app.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="ThrottlingIssue">
                    <serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_IDBInteractionGateway" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
                        maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                    <reliableSession ordered="true" inactivityTimeout="00:10:00"
                        enabled="false" />
                    <security mode="Message">
                        <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="Windows" negotiateServiceCredential="true"
                            algorithmSuite="Default" establishSecurityContext="true" />
                    </security>
                </binding>
            </wsHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:28918/DBInteractionGateway.svc"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IDBInteractionGateway"
                contract="DBInteraction.IDBInteractionGateway" name="WSHttpBinding_IDBInteractionGateway">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>
</configuration>

[Обновление] Решение:

По-видимому, после каждого запроса Вы имеете к Close соединение... Я теперь закрываю соединение после каждого запроса, и это работает как очарование.

Хотя то, что я все еще не могу понять, - то, что в моем app.config, я установил свой maxConcurrentCalls и maxConcurrentSessions к 500, и все же, я могу только сделать 10. У кого-либо есть какой-либо ответ для того? (возможно, у меня есть что-то не так в моем app.config, отправленном выше),

Ответ для вышеупомянутого вопроса (теперь подчеркнутый штриховой линией) - то, потому что я редактировал клиент app.config, не сервисный файл конфигурации (web.config)

39
задан John Saunders 25 August 2012 в 18:17
поделиться

3 ответа

Количество разрешенных одновременных подключений по умолчанию равно 10.
Скорее всего, ваш клиент не закрывает соединения.

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

27
ответ дан markt 27 November 2019 в 02:52
поделиться

Можете ли вы настроить трассировку и запустить цикл? Может случиться так, что канал выйдет из строя и заставит клиента тайм-аут.

0
ответ дан JP Alioto 27 November 2019 в 02:52
поделиться

Нет, это неплохая идея, за исключением того, что вы все испортили.

Во-первых, вы пишете в строковый литерал. Это неопределенное поведение. (Он вылетает в Windows.) Если бы вы написали const char * str = "Hello!" , компилятор рявкнул бы на вас. К сожалению, существует (в C ++ устаревшее, но все же разрешенное) преобразование строкового литерала в неконстантный char * , что позволяет компилировать ваш код. Однако вам нужен массив, в который вы можете записывать (и который предварительно инициализирован). Для этого используйте char str [] = "Hello!" .

Другая, незначительная ошибка заключается в том, что вы дважды перебираете строку: strlen пробегает символы, пока не находит '\ 0' , а затем вы выполняете опять то же самое. Я действительно изменил свой вызов моей службы на Dispose () клиент службы, но, похоже, это не дало никакого эффекта. Очевидно, где-то скрывается еще один служебный вызов.

Что может быть интересно отметить, так это то, что заставило меня решить, что это , а не проблема: этот предел не связан с фактическим количеством сокетов, подключенных к веб-сервис. Когда вы достигнете предела maxConcurrentSessions , останется только одно фактическое соединение с сокетом . Я проверял это с помощью netstat , что привело меня к неправильному выводу. Итак, не путайте сеансы с сокетами .

У нас есть интерфейсы, определенные для всех наших сервисов WCF, поэтому я планирую адаптировать этот шаблон в своем коде сейчас:

IMyService service = new MyServiceClient();
using (service as IDisposable)
{
    service.MyServiceMethod();
}

Что также интересно, в том, что проблема не возникла у меня, когда службы (и веб-сайт) размещались на IIS. Конфигурация (почти) идентична, но мне не удалось воспроизвести такое поведение на этой машине. Думаю, это хорошо :)

@ John Saunders (о присвоении переменных в с использованием ):

Я обычно помещаю присвоение переменных в с использованием оператора . Но созданный IMyService не может быть неявно преобразован в IDisposable . Если бы вы действительно хотели, чтобы это присваивание было там, я полагаю, альтернативой будет:

IService service;
using ((service = new ServiceClient()) as IDisposable)
{
}

Тем не менее, остается проблема с неправильной областью видимости переменной. Ссылка на службу IService непригодна для использования, но все еще остается в силе. Так что в этом отношении было бы лучше:

using (IDisposable serviceDisposable = new ServiceClient())
{
     IService service = (IService)serviceDisposable;
}

Это требует, чтобы я ввел дополнительное имя переменной. * Meh *

1
ответ дан 27 November 2019 в 02:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: