System.Net.WebException: запрос был прерван: запрос был отменен

У меня есть служба WCF, которая выдает мне эту ошибку в условиях загрузки (и я не могу воссоздать ошибку иначе). Мы пытались найти способ обойти это уже около недели, но безуспешно.

Ошибка, которую я вижу, состоит из двух частей:

System.ServiceModel.CommunicationException: Ошибка: (Запрос был прерван: запрос был отменен.) Произошла ошибка при передаче данных по каналу http.

и:

System.Net.WebException: запрос был прерван: запрос был отменен.

Я видел, как многие люди предлагали отключить работу с поддержкой активности, перегрузив метод в файле Reference.cs и установив KeepAlive = false, однако наша клиентская сторона использует ссылку на службу (в дополнение к веб-ссылке), и эта опция больше не существует.

Другой вариант, который я видел, заключался в том, чтобы добавить пользовательскую привязку к службе вместо BasicHttpBinding, которую мы используем сейчас, но это беспокоило бы обратную поддержку веб-службы для тех, кто использовал веб-ссылку (поскольку CustomBinding не поддерживает SOAP).

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


person Audzzy    schedule 10.10.2010    source источник
comment
Вы можете получить доступ к Http Context и делать то, что хотите. Посмотрите здесь: blogs.msdn.com/b/justinjsmith/archive/2007/08/22/   -  person Aliostad    schedule 10.10.2010


Ответы (5)


Я не думаю, что за это отвечает поддержка HTTP. WCF должен быть в состоянии справиться с этим самостоятельно, чтобы постоянное HTTP-соединение распределялось между запросами, и если оно истекает (срок его действия истекает после 100 секунд бездействия) WCF создает новый без каких-либо исключений. Если ваше соединение прерывается во время передачи запроса, я ожидаю, что возникнет какая-то другая проблема.

Вы можете использовать эту пользовательскую привязку как эквивалентную BasicHttpBinding без поддержки HTTP:

<bindings>
  <customBinding>
    <binding name="NoKeepAlive">
      <textMessageEncoding messageVersion="Soap11" />
      <httpTransport keepAliveEnabled="false" />
    </binding>
  </customBinding>
</bindings> 
person Ladislav Mrnka    schedule 10.10.2010
comment
Да, это ответственно, и я видел это раньше. - person Aliostad; 10.10.2010
comment
Вау, я только что испытал это на себе. Какой сюрприз. Спасибо, @Алиостад - person Alexandru; 20.04.2017
comment
@Aliostad Просто из любопытства, вы также звоните в веб-службу Java на основе Tomcat? - person Alexandru; 20.04.2017

У меня была эта проблема при попытке загрузить большие файлы. Мне пришлось добавить это в web.config веб-сервисов.

<system.web>
  <httpRuntime maxRequestLength="10240" />
person nuander    schedule 06.09.2013

У меня была точно такая же проблема. В моем случае я выполнял запросы ASynchronally. Я отправлял несколько сотен запросов на «сервер» от своего клиента. Я использую/использовал basicHttpBinding. И в моей настройке app.config свойство openTimeout было установлено на 60 секунд или одну минуту. Как только я установил большее число, например 10 минут, проблема исчезла.

Так, например, я изменил все эти значения в моем файле app.config:

<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IScriptRunHost" closeTimeout="00:10:00"
                    openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"

до 10 минут.

person C Johnson    schedule 06.09.2011

добавьте это в app.config

 <system.net>
 <connectionManagement>
      <add address="*" maxconnection="5"/>
                <add address="https://api.limitedconnections.com*" maxconnection="2"/>                
                <add address="https://api.moreconnections.com*" maxconnection = "10"/>
        </connectionManagement>
</system.net>

Обратитесь по ссылке ниже

https://cdijkgraaf.wordpress.com/2019/12/02/configuring-maxconnection-in-biztalk/

person Vindya Shree    schedule 30.07.2020

Эта ошибка также может быть вызвана смешиванием предложений using с асинхронными вызовами служб WCF.

Например:

using (ServiceClient proxy = new ServiceClient(proxyName)) {
  proxy.Open();
  return proxy.FunctionCallAsync(parameters); //Return type being Task<ResultSet>
}

Это вызовет состояние гонки между тем, насколько быстро он может избавиться от proxy, и тем, насколько быстро может быть завершено асинхронное Task<ResultSet>. Чем дольше выполняется задача, тем больше вероятность того, что она окажется в состоянии Faulted, а Result будет содержать исключение System.ServiceModel.CommunicationException.

Это можно исправить, удалив предложение using:

ServiceClient proxy = new ServiceClient(proxyName))
proxy.Open();
return proxy.FunctionCallAsync(parameters); //Return type being Task<ResultSet>

Обратите внимание, что proxy также должен быть сохранен, чтобы после завершения асинхронного вызова можно было выполнить proxy.Close().

person Anketam    schedule 06.02.2020