Существующее соединение было принудительно закрыто удаленным хостом - PullRequest
Новая
       8

Существующее соединение было принудительно закрыто удаленным хостом

9 голосов
/ 19 мая 2010

У меня есть толстый VB.NET Winform клиент, который использует старый веб-сервис в стиле asmx. Очень часто, когда я выполняю запрос, который занимает некоторое время или передает большое количество данных веб-службе в наборе данных, я получаю сообщение об ошибке субъекта.

Ошибка возникает через <1 мин, что намного меньше установленного мною значения времени ожидания веб-службы или значения времени ожидания объекта команды ADO, выполняющего запрос на веб-сервере. </p>

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

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Smit.Pipeline.Bo.localhost.WsSR.SaveOptions(String emailId, DataSet dsNeighborhood, DataSet dsOption, DataSet dsTaskApplications, DataSet dsCcUsers, DataSet dsDistinctUsers, DataSet dsReferencedApplications) in C:\My\Code\Pipeline2\Smit.Pipeline.Bo\Web References\localhost\Reference.vb:line 944
   at Smit.Pipeline.Bo.Options.Save(TaskApplications updatedTaskApplications) in

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

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

Эта ошибка действительно хроническая и убивает меня. Пожалуйста, помогите.

Ответы [ 8 ]

2 голосов
/ 13 августа 2012

Этот код решил проблему для меня: 

Socket.ReceiveFrom(Buffer, Net.Sockets.SocketFlags.None, ReceiveEndpoint)
Socket.SendTo(Buffer, Length, Net.Sockets.SocketFlags.None, ReceiveEndpoint)

Когда я использовал функцию с socketsflags, сервер / клиент больше не отключался.

2 голосов
/ 17 сентября 2010

У меня была точно такая же проблема. Вызовы веб-службы не будут выполняться с одним и тем же прерывистым исключением (~ один раз в день). Это не было связано со слишком большими размерами пакетов или слишком маленькими тайм-аутами.

В итоге я просто ввел некоторую логику повторных попыток, которая обошла проблему. См .: Как улучшить этот сценарий повторения исключений?

2 голосов
/ 19 мая 2010

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

.

Чтобы изменить это, либо поместите его в конфигурацию привязки (maxReceivedMessageSize, maxBufferSize и maxArrayLength являются ключевыми свойствами для этого) в файле app.config, либо программно, изменив свойство привязки, например 

System.ServiceModel.BasicHttpBinding binding = new System.ServiceModel.BasicHttpBinding();

// if you are getting a LOT of data back, you will need to up Message Size
binding.MaxReceivedMessageSize = int.MaxValue;

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

Если возможно, используйте WCF для веб-сервисов. Это решает множество проблем, от которых по-прежнему страдают сервисы ASMX.

Чтобы увеличить лимит передачи на стороне сервера и время ожидания выполнения, используйте это 

<configuration>
  <system.web> 
    <httpRuntime maxMessageLength="409600" executionTimeoutInSeconds="300"/> 
  </system.web>
</configuration>
1 голос
/ 23 января 2017

В моем случае мой общий обработчик HTTP (handler.ashx) испытывал неожиданно оборванное соединение при попытке извлечь большие файлы из службы WCF. В конце концов ответ пришел на одной веб-странице Microsoft (https://msdn.microsoft.com/en-us/library/ms733742.aspx)) и на звонок в Microsoft, который сказал мне, что один критический элемент на этой странице был написан с ошибкой (должен был быть «Потоковый» вместо «Потоковый») Исправленный фрагмент кода с этой страницы, примененный к файлу app.config моей службы WCF, выглядит следующим образом: 

<system.serviceModel>
<bindings>
    ...
    <basicHttpBinding>
    <binding name="ExampleBinding" transferMode="Streamed"/>
        </basicHttpBinding>
    </bindings>
    ...
<system.serviceModel>

Ключ должен был установить режим передачи.

1 голос
/ 24 октября 2013

Если это ASP.NET, попробуйте установить максимальное значение maxRequestLength в файле web.config 

<httpRuntime maxRequestLength="65536"/>

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

С уважением,

Mafaz

0 голосов
/ 16 февраля 2015

Хорошо, я получил ту же ошибку. Но в моем случае проблема была в программном обеспечении AV, которое блокировало службы отчетов локально.

0 голосов
/ 18 июня 2014

Для IIS 7 (в моем случае) идентификатором пула приложений веб-службы было «ApplicationPoolIdentity». Я назначил локальному пользователю, и он работал просто отлично.

0 голосов
/ 17 марта 2011

попробуйте это, у меня это работает на 10000 отправленных через сетевой поток

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

**YourInstantTcpClient**.SendBufferSize = 6550000

Извините, я тайский человек, пусть мой английский не очень хороший.

...