Прервать асинхронный вызов веб-службы и перенаправить на другой URL-адрес (ASP.NET Ajax) - PullRequest
Новая
       23

Прервать асинхронный вызов веб-службы и перенаправить на другой URL-адрес (ASP.NET Ajax)

1 голос
/ 21 июля 2009

В моем веб-приложении у меня есть список ссылок, созданных на основе кода и привязанных к элементу управления повторителем. При нажатии на ссылку открывается всплывающее окно, в котором наряду с отображением некоторых данных выполняется асинхронный вызов службы WCF (через прокси-сервер javascript). Эта служба, в свою очередь, вызывает другую стороннюю веб-службу, которая может занять много времени для ответа. Я работаю с IE6, это неизбежное требование.

Теперь я прекращаю эту услугу при onunload, если пользователь решает не ждать завершения вызова и просто закрывает всплывающее окно. Проблема заключается в том, что если пользователь щелкает другую ссылку сразу после повторителя, открывается новое всплывающее окно, но он не загружает страницу (не переходит по указанному URL-адресу) до завершения предыдущего асинхронного вызова (я проверил это через фиддлера). Интересно, что это происходит только для ссылок в пределах одного домена. Если я изменю ссылку для одной из папок, скажем, на www.google.com, то откроется окно и перейдет на правильный URL-адрес, как и предполагалось. Но для всплывающих окон со ссылками в моем собственном домене, которые открываются сразу после закрытия всплывающего окна с незавершенным запросом, он ожидает завершения предыдущего запроса, прежде чем загружать URL.

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

//Method to Call Service:

    function GetData(Id) {

            //call the service

            Sys.Net.WebRequestManager.add_invokingRequest(On_InvokingRequest);

            var service = new WrapperService();
            service.GetData(Id, handleSuccess, handleError, null);

            Sys.Net.WebRequestManager.remove_invokingRequest(On_InvokingRequest);
        }

//method to get the current requests abort executor
function On_InvokingRequest(executor, eventArgs) {
        var currentRequest = eventArgs.get_webRequest();
        abortExecutor = currentRequest.get_executor();
    }

//abort service on unload
function unload() {
        if (abortExecutor != null) {
            abortExecutor.abort();
        }
    }

Полезные / Похожие ссылки на фон:

браузер-ждет-на-Ajax-призыв к полному четному после прерывания-было-были-востребованным JQuery прерывание-ан-Asp-нетто-веб-сервис асинхронный вызов отмена-Ajax-веб-сервис вызова

Кто-нибудь сталкивался с этим раньше? Это сводит меня с ума! Любая помощь будет принята с благодарностью.

1 Ответ

0 голосов
/ 21 июля 2009

Ответ в одной из ваших ссылок звучит как проблема для меня: Браузер ожидает завершения вызова ajax даже после вызова прерывания (jQuery)

Требует ли ваша служба состояния сеанса?

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

Настройка IE для более чем 2 запросов: http://support.microsoft.com/kb/282402

Цитата одного из SO вопросов, которые вы связали:

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

К сожалению, в этом случае в сеансе http, отвечающем на вызовы ajax, требуется состояние сеанса. Но доступ только для чтения достаточно хорош, поэтому, пометив обработчик IReadOnlySessionState вместо IRequiresSessionState, блокировки сеанса не удерживаются и проблема устранена.

...