Как: веб-сервис и Клиентские Тайм-ауты обработки в веб-сервисе?

Используя StreamReader для преобразования MemoryStream в Строку.

<Extension()> _
Public Function ReadAll(ByVal memStream As MemoryStream) As String
    ' Reset the stream otherwise you will just get an empty string.
    ' Remember the position so we can restore it later.
    Dim pos = memStream.Position
    memStream.Position = 0

    Dim reader As New StreamReader(memStream)
    Dim str = reader.ReadToEnd()

    ' Reset the position so that subsequent writes are correct.
    memStream.Position = pos

    Return str
End Function
7
задан Wolf5 12 August 2009 в 12:15
поделиться

6 ответов

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

Что вам следует сделать, так это узнать, какие веб-методы занимают слишком много времени. Вы можете начать делать это, включив трассировку, как показано в разделе « Включение трассировки в веб-службах ASP.NET ». Затем вам, возможно, придется пойти дальше и профилировать службу, чтобы увидеть, на что тратится время.

Также следует внимательно просмотреть журналы событий. В частности, ищите предупреждающие события из источника событий «ASP.NET». Они взяты из ASP.NET Health Monitoring .

1
ответ дан 8 December 2019 в 01:44
поделиться

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

Итак, можно ли окружить вызов ловушкой попытки?

0
ответ дан 8 December 2019 в 01:44
поделиться

Протокол HTTP не имеет спецификации, как сервер может пинговать клиента. Смысл IsClientConnected - проверить, существует ли какой-нибудь «неудовлетворенный» запрос для рендеринга HttpResponse. И может быть (я не уверен), если клиент поддерживает keep-connection-alive.

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

0
ответ дан 8 December 2019 в 01:44
поделиться

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

Учтите, что в целом веб-сервис не должен даже использовать такой транспорт, как HTTP, вы можете отвечать через очереди или даже по электронной почте. Как правило, вы, как серверная реализация простой веб-службы, не можете быть уверены, что ваш клиент увидел ответ. Что бы вы сделали, если бы ваш тест работал? В тот момент, когда вы сделали тест, он там, через наносекунду после того, как вы решили не входить в систему, но до того, как вернетесь, он ушел. В простом протоколе SOAP / HTTP нет транзакционных отношений между клиентом и сервером.

Существуют дополнительные стандарты веб-служб для решения некоторых из этих проблем, но обычно вам нужно проектировать свои веб-службы, исходя из предположения, что вызывающий может не увидеть ответа. (возможно, вы также предоставляете услуги по отслеживанию состояния, чтобы клиент мог уйти, а затем вернуться и спросить: «Вы обработали заказ« 345 »»).

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

0
ответ дан 8 December 2019 в 01:44
поделиться

Я думаю, что для того, чтобы IsClientConnected возвращал false, часть кода вашего веб-сервиса, которая говорит: «// .. Делайте материал веб-сервиса», должна выполняться дольше, чем настройка тайм-аута клиента. Вероятно, вы могли бы смоделировать это, установив тайм-аут клиента на 60 секунд и поместив Thread.Sleep (70000) в код веб-службы перед вызовом IsClientConnected.

Однако я не думаю, что даже это приведет к тому, что IsClientConnected вернет false . Тайм-аут запроса веб-службы и сброс соединения с сервером - два разных зверя. Если бы Response имел метод с именем IsClientStillWaitingForThisWebServiceCallToReturn, он мог бы делать то, что вы хотите.

0
ответ дан 8 December 2019 в 01:44
поделиться

Лучше подписаться на какое-то событие, чем проверять какой-то флаг. По сути, ASP.NET убивает запрос, потому что он занимает больше времени, чем настроенное значение тайм-аута (параметр executionTimeout в элементе httpRuntime). Однако я не уверен, есть ли такое событие из среды выполнения ASP.NET. Видимо, никаких исключений это тоже не вызывает. Таким образом, в этом конкретном случае, похоже, существует разрыв между вашей службой и средой выполнения ASP.NET. Мне было бы интересно узнать, есть ли способ / уловка для достижения того, что вам нужно.

А пока вы можете изучить счетчики производительности ASP.NET. Один из них называется «Истекло время ожидания запросов». Он может включать запросы, время ожидания которых истекло во время ожидания в очереди или во время выполнения. Вы можете прочитать счетчик производительности своего веб-сервиса в начале и в конце вашего веб-метода. Если число подскочило, значит, запрос просто истек. Это может не обязательно означать, что переход соответствует этому конкретному запросу, но в любом случае вы все равно можете регистрировать некоторую информацию, такую ​​как параметры, переданные веб-методу, прошедшее время и т. Д., Которая может быть полезной. Вы также можете увеличить значение executionTimeout в web.config, чтобы у вас было больше времени, пока вы пытаетесь оптимизировать свой веб-метод для более быстрой работы, если у вас есть клиенты, которым требуется немедленное решение.

Если это веб-служба asmx, вам может потребоваться посмотреть событие Session_End в global.asax. Он может быть вызван, когда ASP.NET завершает запрос.

Просто некоторые мысли.

Это может не обязательно означать, что переход соответствует этому конкретному запросу, но в любом случае вы все равно можете регистрировать некоторую информацию, такую ​​как параметры, переданные веб-методу, прошедшее время и т. Д., Которая может быть полезной. Вы также можете увеличить значение executeTimeout в web.config, чтобы дать больше времени, пока вы пытаетесь оптимизировать свой веб-метод для более быстрой работы, если у вас есть клиенты, которым требуется немедленное решение.

Если это веб-служба asmx, вам может потребоваться посмотреть событие Session_End в global.asax. Он может быть вызван, когда ASP.NET завершает запрос.

Просто некоторые мысли.

Это может не обязательно означать, что переход соответствует этому конкретному запросу, но в любом случае вы все равно можете регистрировать некоторую информацию, такую ​​как параметры, переданные веб-методу, прошедшее время и т. Д., Которая может быть полезной. Вы также можете увеличить значение executeTimeout в web.config, чтобы дать больше времени, пока вы пытаетесь оптимизировать свой веб-метод для более быстрой работы, если у вас есть клиенты, которым требуется немедленное решение.

Если это веб-служба asmx, вам может потребоваться посмотреть событие Session_End в global.asax. Он может быть вызван, когда ASP.NET завершает запрос.

Просто некоторые мысли.

config, чтобы дать вам больше времени, пока вы пытаетесь оптимизировать свой веб-метод, чтобы он работал быстрее, если у вас есть клиенты, которым требуется немедленное решение.

Если это веб-служба asmx, вы можете изучить событие Session_End в global.asax . Он может быть вызван, когда ASP.NET завершает запрос.

Просто некоторые мысли.

config, чтобы у вас было больше времени, пока вы пытаетесь оптимизировать свой веб-метод, чтобы он работал быстрее, если у вас есть клиенты, которым требуется немедленное решение.

Если это веб-служба asmx, вы можете изучить событие Session_End в global.asax . Он может быть вызван, когда ASP.NET завершает запрос.

Просто некоторые мысли.

-1
ответ дан 8 December 2019 в 01:44
поделиться
Другие вопросы по тегам:

Похожие вопросы: