WCF Исключение для длинных операций: netTcpBinding - PullRequest
Новая
       6

WCF Исключение для длинных операций: netTcpBinding

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

У нас есть следующий netTcpBinding в сервисе. В одном конкретном случае у нас есть огромная операция с базой данных, которая занимает около 35 минут. Я получаю исключение «Соединение с сокетом было прервано». Какие настройки мне следует изменить, чтобы избежать исключения?

Примечание: я получаю исключение почти через 10 минут. Каковы значения конфигурации, для которых значение по умолчанию составляет 10 минут?

Framework: .Net 3.0

ОБНОВЛЕНИЕ : Когда я применил receiveTimeout = "00:30:00", теперь примерно через 5 минут появляется следующая ошибка IE: "Система не может связаться с внешним сервером".

До применения, это была пользовательская страница ошибок наших приложений. Любая идея, что я должен изменить сейчас?

Примечание. Это происходит на промежуточном сервере. (Эта проблема недоступна в нашей среде разработчиков до и после)

Примечание. Для Staging веб-приложение размещено в IIS. WCF размещается в службе Windows 

    <bindings>

        <netTcpBinding>


            <binding name="AdministrationBinding" maxReceivedMessageSize="2147483647">
                <readerQuotas maxDepth="32" 
                    maxStringContentLength="2147483647" 
                    maxArrayLength="2147483647" 
                    maxBytesPerRead="2147483647" 
                    maxNameTableCharCount="16384"/>
            </binding>
        </netTcpBinding>

    </bindings>

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

    <binding name="NetTcpBinding_IAdministrationManager" 
             closeTimeout="00:30:00" 
             openTimeout="00:30:00" 
             receiveTimeout="00:30:00" sendTimeout="00:30:00" 
             transactionFlow="false" transferMode="Buffered" 
             transactionProtocol="OleTransactions" 
             hostNameComparisonMode="StrongWildcard" 
             listenBacklog="10"
             maxBufferPoolSize="524288" 
             maxBufferSize="2147483647" 
             maxConnections="10"     
             maxReceivedMessageSize="2147483647">

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

      <reliableSession ordered="true" 
             inactivityTimeout="00:30:00" enabled="false"/>

      <security mode="Transport">
        <transport clientCredentialType="Windows" 
             protectionLevel="EncryptAndSign"/>
        <message clientCredentialType="Windows"/>

      </security>

    </binding>

Спасибо

Lijo

Ответы [ 3 ]

2 голосов
/ 20 июня 2011

Вам также необходимо добавить значения не по умолчанию для различных тайм-аутов на стороне сервера.Технически, не все тайм-ауты эффективны / полезны для обеих сторон (отправка против получения, открытие против закрытия), но для простоты вы можете просто отразить их по обе стороны.

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

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

Я думаю, может быть лучше иметьдлинные операции происходят асинхронно на сервере, и метод немедленно возвращается.Если вам нужно уведомление на стороне клиента о завершении операции, вы можете использовать обратный вызов.

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

Параметр receiveTimeout в сервисе по умолчанию равен 10 минутам - это то, как долго сервис будет ждать запросов, прежде чем решить, что прокси-сервер пропал.Вам нужно будет увеличить это.Тем не менее, вы делаете синхронный звонок в течение 35 минут?

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

...