Долгосрочная калитка Ajax Request - PullRequest
4 голосов
/ 05 марта 2010

В моем приложении Wicket время от времени появляются длительные запросы AJAX. Когда это происходит, приложение в значительной степени невозможно использовать, поскольку последующие запросы AJAX ставятся в очередь для синхронной обработки после текущего запроса. Я хотел бы, чтобы запрос завершался через определенный промежуток времени, независимо от того, был ли возвращен ответ (у меня есть требование пользователя, чтобы в этом случае мы сообщали пользователю об ошибке и продолжали). Это представляет два вопроса:

  1. Есть ли способ указать тайм-аут, специфичный для AJAX или все запросы AJAX?
  2. Если нет, есть ли способ убить текущий запрос?

Я просмотрел файл wicket-ajax.js и не вижу упоминаний об истечении времени ожидания запроса.

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

Спасибо!

Ответы [ 2 ]

3 голосов
/ 06 марта 2010

Я думаю, что это не поможет вам разрешить клиенту «отменить» запрос. (Однако это может сработать.)

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

Относительно вашей проблемы с очередями: вы можете рассмотреть возможность использования асинхронных запросов, несмотря на синхронные. Это означает, что клиент сначала отправляет запрос на запуск длительного процесса. Этот запрос немедленно возвращается. Затем клиент периодически опрашивает сервер и спрашивает, завершился ли процесс. Эти запросы также немедленно возвращаются, сообщая, что процесс все еще выполняется или завершился с определенным результатом.

2 голосов
/ 05 марта 2010

Неудачное решение: после заданного setTimeout я убиваю активные транспорты и перезапускаю канал, который обрабатывает все на стороне клиента.Я избежал конфликтов запросов, связывая каждый из них с идентификатором и проверяя его по глобальной ссылке, которая увеличивается каждый раз, когда выполняется запрос, и каждый раз, когда запрос завершается.все последующие вызовы ожидают завершения запроса на стороне сервера.

На этом этапе мое решение состоит в том, чтобы вместо этого предоставить пользователю возможность выхода из системы с помощью BookmarkablePageLink (который создает новую страницу, таким образом, не вызывая конфликтКарта страницы).Определенно не оптимально.

Любые лучшие решения более чем приветствуются, но это лучшее, что я мог придумать.

...