Есть некий вебсервис, при небольших объемах(2.5мин времени, 500кб входящей инфы, 2Мб исходящей) перерабатываемой инфы отлично работает, решил увеличить нагрузку в 1.5 раза, соответственно увеличил таймауты и т.д, и тут неожиданно клиенты начали падать с ошибкой
1.soap toolkit 3.0 — явный намек на нехватку памяти у сервиса
Connector:Connection failed or server refused connection (request might exceed MaxPostSize). HRESULT=0x800A151E — Client:An unanticipated error occurred during the processing of this request. HRESULT=0x800A151E — Client:Sending the Soap message failed or no recognizable response was received HRESULT=0x800A151E — Client:Unspecified client error. HRESULT=0x800A151E
2.NET клиент — тут ваще глухо
InnerException {"Unable to read data from the transport connection: Удаленный хост принудительно разорвал существующее подключение."} System.Exception {System.IO.IOException}

Самое интересное — сервис успешно выполняется до конца — в системный лог пишу инфу об этом
Инфы в системном логе, почему генерится ошибка при выходе из моего сервиса, нет.

Добавил к сервису атрибут — BufferResponse = false, таже песня, но в системном логе появляется запись

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 16.08.2006 15:29:12
Event time (UTC): 16.08.2006 11:29:12
Event ID: 9f1d8f820c72495d8e688e9ff89d0061
Event sequence: 6
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/Root/WebService-1-128002011191396697
Trust level: Full
Application Virtual Path: /WebService
Application Path: c:\inetpub\wwwroot\WebService\
Machine name: MYCOMP

Process information:
Process ID: 4476
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: HttpException
Exception message: Server cannot clear headers after HTTP headers have been sent.

Request information:
Request URL: http://MYCOMP/WebService/Bridge.asmx
Request path: /WebService/Bridge.asmx
User host address: 168.144.14.91
User: MYDOM\MYUSER
Is authenticated: True
Authentication Type: Negotiate
Thread account name: MYDOM\MYUSER

Thread information:
Thread ID: 1
Thread account name: MYDOM\MYUSER
Is impersonating: True
Stack trace: at System.Web.HttpResponse.ClearHeaders()
at System.Web.Services.Protocols.SoapServerProtocol.WriteException(Exception e, Stream outputStream)
at System.Web.Services.Protocols.WebServiceHandler.WriteException(Exception e)
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Custom event details:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

По адресу go.microsoft.com/fwlink/events.asp уже нет инфы про ивенты, поискал в инете про эту ошибку — что совсем кисло. Типа, может кто сталкивался с такой проблемой или может что подсказать.

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

Здравствуйте, Sacode, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:

А>>Есть некий вебсервис, при небольших объемах(2.5мин времени, 500кб входящей инфы, 2Мб исходящей) перерабатываемой инфы отлично работает, решил увеличить нагрузку в 1.5 раза, соответственно увеличил таймауты и т.д, и тут неожиданно клиенты начали падать с ошибкой
А>>1.soap toolkit 3.0 — явный намек на нехватку памяти у сервиса
А>>Connector:Connection failed or server refused connection (request might exceed MaxPostSize).

S>Так, вроде, сказали же, что "request might exceed MaxPostSize". Слишком большой запрос. Соответственно надо подкрутить этот MaxPostSize.
S>В .Net следующая строка в Web.Config'е для подкручивания, например, размера запроса:
S>
S><system.web>
S>        <httpRuntime maxRequestLength="10240" />
S>        ...
S>
S>Где это делается в SOAP Toolkit — не знаю.

Параметр maxRequestLength стоит достаточный для возврата, SOAP Toolkit думает, что сервис сделан при помощи него же, а параметр MaxPostSize находится в реестре.Но сервис сделан на .NET и если бы не хватало maxRequestLength, то клиенту на .NET вовращалось бы прямое сообщение об этом (это уже проходили), а тут "сервер разорвал коннекшен", где-то должен быть еще какой-то параметр отвечающий за размер памяти отводимой задаче, выполняющей сервис.
Сегодня ради интереса зациклил выполнение сервиса, 7% — исполняется успешно, остальные с ошибкой.

Здравствуйте, mclabman, Вы писали:

M>Копай в сторону прокси. Посмотри, что действительно приходит на клиента.

ОК, надо действительно пройтись отладчиком.

Здравствуйте, mclabman, Вы писали:

M>Да не отладчиком, а telnetом.

M>
данное сообщение получено с www.gotdotnet.ru
M>ссылка на оригинальное сообщение

Я то думал ты про прокси-объект.
Дык у меня сервер с клиентом на двух соседних машинах, никакого прокси нет, что телнетом смотреть?

Здравствуйте, mclabman, Вы писали:

M>Да не отладчиком, а telnetом.

M>
данное сообщение получено с www.gotdotnet.ru
M>ссылка на оригинальное сообщение

Надо будет на одной тачке и клиента и сервис попробовать.
Еще конечно можно сниффером пакеты посмотреть.
Или ты по-поводу прокси предлагаешь клиента с сервисом через прокси связать?И в прокси смотреть пакеты?
Я правильно понял?

Здравствуйте, mclabman, Вы писали:

M>Нет, я имел в виду следующее: похожие ошибки возникали, когда прокси-сервер проглатывал 100-continue от клиента.
M>Сравни то, что ты получаешь по HTTP при вызове метода на самом сервере и на клиенте. TCP смотреть не надо.


M>
данное сообщение получено с www.gotdotnet.ru
M>ссылка на оригинальное сообщение

Спасибо за участие и за идею перехватить трафик между прогами.
Но в моем случае между клиентом и сервером нет прокси, они в одной сетке и их ip отличаются на 1.

Здравствуйте, 1, Вы писали:

1>А тут был?

1>
данное сообщение получено с www.gotdotnet.ru
1>ссылка на оригинальное сообщение

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