Почему же нет asyncContext.cancel()

В то время как спецификации сервлетов 3.0 имеет request.startAsync() и asyncContext.start(), почему он не предоставил asyncContext.stop() или asyncContext.cancel() инициировать необходимую очистку на стороне сервера?Почему же нет asyncContext.cancel()

Pls рассматривает это в контексте этого другого question, чтобы понять, откуда я.

Один запроса HTTP начинает обработку Async и возвращает ссылку .../outstandingRequests/RequestID клиента.
Другой HTTP вызовы запрос DELETE на эту ссылку, чтобы отменить запрос

В этом случае, если у меня был способ очистить вверх на стороне сервера (сервлет контейнер материал как AsyncListeners), вместо того, чтобы звоните asyncContext.complete(), который, вероятно, попытается отправить ответ клиенту, это будет иметь смысл. Не так ли?

источник

2013-05-02 brainOverflow

В этом случае вызов 1 все еще висит там, ожидая ответа, когда приходит вызов 2 и хочет его убить. В этом случае, почему вы не хотите вызывать complete() по вызову 1, таким образом, заканчивая этот вызов, чтобы клиент переставал ждать? Вероятно, вы захотите установить код состояния на что-то отличное от 200 в этом типе ситуации, но complete кажется слишком лучшим вариантом для любого сценария, потому что он возвращает управление обратно исходному абоненту и выполняет любую работу по очистке, связанную с запросами.

Когда происходит тайм-аут, который является ошибкой, контейнер вызывает complete (с учетом кода ответа, отличного от 200). Сценарий, который вы описываете, похож на тайм-аут (хотя и вынужденный тайм-аут), поэтому почему бы не сделать то же самое, что делает контейнер. Просто позвоните что-то вроде этого перед вызовом complete:

ac.getResponse().setStatus(500);

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

источник

2013-05-03 19:40:14 cmbaxter

Я беспокоюсь о побочных эффектах вызова complete() в случае отмены: «Любые слушатели типа AsyncListener, зарегистрированные в ServletRequest, для которых был создан этот AsyncContext, будут вызваны по методу onComplete.». Если слушатель должен рассмотреть это как успешное завершение (тривиальный пример: увеличивайте счетчик SuccessfulRequestsHandled), я столкнулся бы с проблемой. Это похоже на перегрузку complete() со многими значениями! – brainOverflow

В вызове onComplete используется AsyncEvent, который позволяет вам получить доступ к HttpServletResponse. В вашем слушателе вы можете проверить код состояния и действовать соответственно, если не 200. Вы также можете создать класс абстрактного слушателя, который инкапсулирует эту проверку и делегирует вместо onError, если код статуса не 200. Тогда просто все ваши пользовательские слушатели простираются от этого. – cmbaxter

Это приемлемое решение! Но это по-прежнему круто! Я думаю, если мы растянем этот аргумент, AsyncListener может просто сделать с одним методом обратного вызова, скажем, onComplete(), а затем потребовать от программиста установить соответствующий код состояния и определить, является ли это тайм-аутом, ошибкой или успехом или отменить! Он может покончить с onTimeout() и onError()! Я честно чувствую, что спецификация Async Servlet не тратила много времени, думая об отмене! – brainOverflow

-1

ac.getResponse(). SetStatus (500); не работает?

источник

2015-06-29 15:12:07 Reuben

должен быть комментарий не ответ – TheCodingFrog

ответ

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