2009-07-20 8 views
1

Dans ma webapp, j'ai une liste de liens générés à partir de code-behind et liés à un contrôle de répéteur. Cliquer sur un lien ouvre une fenêtre contextuelle où, avec l'affichage de certaines données, un appel asynchrone à un service WCF est effectué (via un proxy javascript). Ce service appelle à son tour un autre service Web tiers qui peut prendre beaucoup de temps pour répondre. Je travaille avec IE6, c'est une exigence incontournable. Maintenant, j'abandonne ce service sur onunload si l'utilisateur décide de ne pas attendre la fin de l'appel et ferme simplement la fenêtre contextuelle. Le problème est que si l'utilisateur clique immédiatement sur un autre lien du répéteur, la nouvelle fenêtre contextuelle s'ouvre mais ne charge pas la page (ne va pas à l'URL fournie) jusqu'à ce que l'appel asynchrone précédent soit terminé (j'ai vérifié cela à travers Fiddler). Fait intéressant, cela se produit uniquement pour les liens au sein du même domaine. Si je change le lien pour l'un des popus, par exemple, www.google.com, la fenêtre s'ouvre et va à l'URL correcte comme prévu. Mais, pour les popups avec des liens dans mon propre domaine, qui sont ouverts immédiatement après la fermeture d'une fenêtre contextuelle avec une requête inachevée, il attend que la requête précédente se termine avant de charger l'URL.Abandonner un appel de service Web asynchrone et rediriger vers une autre URL (ASP.NET Ajax)

J'ai vérifié la manière correcte d'annuler un rappel et l'abandon se déclenche correctement. Je sais aussi que je ne peux qu'abandonner mon appel côté client, et non l'appel côté serveur et je m'en fous. Ma seule exigence est que le navigateur charge le lien suivant quelle que soit la réponse asynchrone précédente.

//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(); 
     } 
    } 

Liens utiles/similaires pour l'arrière-plan:

browser-waits-for-ajax-call-to-complete-even-after-abort-has-been-called-jquery aborting-an-asp-net-web-service-asynchronous-call canceling-ajax-web-service-call

Tout le monde a fait face auparavant? Cela me rend fou! Toute aide est la bienvenue.

+0

Lorsque vous dites que la fenêtre suivante "attend" que la requête précédente soit terminée, voulez-vous dire que le navigateur se bloque? IE pouvez-vous interagir avec le chrome du navigateur pendant qu'il "attend" (glisser la fenêtre, fermez-le, etc)? –

+0

Problème de sondage similaire: http://stackoverflow.com/questions/615592/ie-hang-for-5-minutes-when-calling-synchronous-xmlhttprequest –

+0

@cresentfresh - non je ne peux pas interagir..Il montre juste l'icône de chargement dans la barre d'état, mais attend l'appel précédent pour terminer avant de faire quoi que ce soit – desigeek

Répondre

0

La réponse dans un de vos liens semble que le problème pour moi: Browser waits for ajax call to complete even after abort has been called (jQuery)

Votre service nécessite l'état de session?

Vous pouvez prouver si le problème est que IE lui-même n'émettra pas la demande en configurant IE pour permettre plus de 2 requêtes au même domaine. Si elle est bloquée parce que la requête avortée est en train de manger l'une de ces connexions, alors l'augmenter devrait donner des résultats différents. Si le problème persiste, il faut que le serveur attende pour répondre.

Configurer IE pour plus de 2 demandes: http://support.microsoft.com/kb/282402

Citation de l'une des questions liées SO:

Il se trouve que je me trompais complètement à ce sujet d'être un problème de navigateur - le problème était sur le serveur. ASP.NET sérialise les demandes de la même session qui requièrent un état de session. Dans ce cas, la page suivante n'a pas commencé le traitement sur le serveur tant que ces requêtes initiées ajax ne sont pas terminées.

Malheureusement, dans ce cas, l'état de session est requis dans le gestionnaire http qui a répondu aux appels ajax. Mais l'accès en lecture seule est suffisant, donc en marquant le gestionnaire avec IReadOnlySessionState au lieu de IRequiresSessionState, les verrous de session ne sont pas conservés et le problème est résolu.

Questions connexes