Длинный запуск Wicket Ajax Request

Question

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

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

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

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

Спасибо!

Answer 1

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

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

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

Answer 2

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

function longRunningCallCheck(refId) { 
    // make sure the reference id matches the global id. 
    // this indicates that we are still processing the 
    // long running ajax call. 
    if(refId == id){ 
     // perform client processing here 

     // kill all active transport layers 
     var t = Wicket.Ajax.transports; 
     for (var i = 0; i < t.length; ++i) { 
      if (t[i].readyState != 0) { 
       t[i].onreadystatechange = Wicket.emptyFunction; 
       t[i].abort(); 
      } 
     } 

     // process the default channel 
     Wicket.channelManager.done('0|s'); 
    } 
} 

К сожалению, это по-прежнему оставило блокировку PageMap и любые последующие вызовы ожидают завершения запроса на стороне сервера.

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

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