WCF: Основное соединение было закрыто: соединение было неожиданно закрыто

Поскольку это очень распространенная проблема, но нет правильного решения, которое может решить эту проблему. Я также испытываю это: «Закрытие соединения было закрыто: неожиданно было неожиданно закрыто соединение» для моих веб-служб WCF, но это случайный случай, и нет конкретного сценария, через который я могу воспроизвести. Я пытался решить эту проблему с двух недель и пробовал все возможные решения, включая увеличение тайм-аута, включение/выключение соединения keep-alive, открытие нового соединения для каждого запроса, а затем закрытие сразу после завершения запроса, но есть не повезло. Я также включил отслеживание и протоколирование как на стороне сервера, так и на стороне клиента, но не смог найти такую конкретную проблему, которая может вызвать эту проблему.WCF: Основное соединение было закрыто: соединение было неожиданно закрыто

Эти веб-службы WCF SOAP, развернутые на серверной среде Windows, с помощью IIS 7 и .Net Framework 4.0

стороне клиента Трассировка:

System.Net.Sockets Verbose: 0 : [351180] 00000000 :             : 
    DateTime=2017-01-20T14:25:44.4000839Z 
System.Net.Sockets Verbose: 0 : [351180] Exiting Socket#34051556::Receive()  -> Int32#0 
    DateTime=2017-01-20T14:25:44.4000839Z 
System.Net.Sockets Verbose: 0 : [351180] Socket#34051556::Dispose() 
    DateTime=2017-01-20T14:25:44.4000839Z 
System.Net Error: 0 : [351180] Exception in HttpWebRequest#40245115:: - The underlying connection was closed: The connection was closed unexpectedly.. 
    DateTime=2017-01-20T14:25:44.4157088Z 
System.Net Error: 0 : [351180] Exception in HttpWebRequest#40245115::GetResponse - The underlying connection was closed: The connection was closed unexpectedly.. 
    DateTime=2017-01-20T14:25:44.4157088Z

Server Side Tracing:

System.Net.Sockets Verbose: 0 : [10808] Exiting DNS::GetHostByName() -> IPHostEntry#31978062 
    DateTime=2017-01-20T14:16:20.7036270Z 
System.Net.Sockets Verbose: 0 : [10808] Exiting DNS::GetHostAddresses()  -> IPAddress[]#52697188 
    DateTime=2017-01-20T14:16:20.7036270Z 
System.Net.Sockets Verbose: 0 : [10808] DNS::GetHostAddresses() 
    DateTime=2017-01-20T14:25:03.3938764Z 
System.Net.Sockets Verbose: 0 : [10808] DNS::GetHostByName() 
    DateTime=2017-01-20T14:25:03.3938764Z 
System.Net.Sockets Verbose: 0 : [10808] Exiting DNS::GetHostByName() -> IPHostEntry#39699746 
    DateTime=2017-01-20T14:25:03.4094763Z 
System.Net.Sockets Verbose: 0 : [10808] Exiting DNS::GetHostAddresses()  -> IPAddress[]#12400315 
    DateTime=2017-01-20T14:25:03.4094763Z

Tracing Config:

<system.diagnostics> 
    <trace autoflush="true" /> 
    <sources> 
      <source name="System.ServiceModel" 
        switchValue="Critical, Error, Warning, Verbose , Information, ActivityTracing" 
        propagateActivity="true"> 
      <listeners> 
       <add name="sdt" 
        type="System.Diagnostics.XmlWriterTraceListener" 
        initializeData= "c:\stacktrace_log.log" /> 
      </listeners> 
     </source> 
    </sources> 
</system.diagnostics>

Буду признателен, если кто-нибудь может помочь решить эту проблему.

источник

2017-01-31 Shahid Iqbal

Как вопрос «очень» ясное единственное, что я могу сделать, это угадать. Я думаю, что что-то рушится на стороне сервера. Чтобы получить более подробную информацию [включить трассировку] (https://msdn.microsoft.com/en-us/library/ms733025 (v = vs.110) .aspx) - это обычная отправная точка для этой ошибки. – Reniuz

Как я уже говорил, я включил трассировку и ничего не нашел. –

Извините, я не верю. Докажите это. – Reniuz

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

источник

2017-02-02 15:45:36

Шахид. Не могли бы вы объяснить, что вы сделали, чтобы решить эту проблему. Я столкнулся с той же проблемой. –

Как я уже объяснял ранее, в моем случае проблема с нашим балансировщиком нагрузки, у которого был предельный тайм-аут соединения, установленный на 40 секунд, и когда вызов занимает более 40 секунд, балансировщик был тайм-аутом, и служба выдавала эту ошибку, не указывая дальнейших подробностей, даже в явном виде ничего не было видно трассировка стека. Это очень общая ошибка, которую вы можете отслеживать, помещая некоторые пользовательские протоколирования в свой код. –

WCF: Основное соединение было закрыто: соединение было неожиданно закрыто

ответ

Смежные вопросы