J'ai un appel de service de longue course, que j'appelle à l'aide de jquery.ajax. Le service peut accomplir plus de 2 minutes à compléter.
La demande Ajax est soumise et aucune réponse n'est attendue. Une demande d'Ajax séparée des rapports sur l'avancement de l'opération. P>
sur certains sites, nous avons trouvé que, après 2 minutes, l'agent soumet la demande Ajax elle-même. Le navigateur est chrome, mais je doute de sa question liée au chrome. P>
Ce n'est certainement pas un cas de re soumettre à nouveau la demande Ajax. Pour être sûr que nous définissons un bool pour empêcher toute nouvelle soumission dans l'événement Beforesend. P>
La manière dont je traite maintenant la manipulation de cette nouvelle soumission, consiste à ajouter une nonce à la demande de données et aux tests de service Si la nonce a déjà été soumise avant d'effectuer son fonctionnement. N'importe quel second appel à ce service revient sans danger et que la demande initiale continue de progresser. P>
Notez que j'ai ajouté un service inutile qui n'attend que 5 minutes, et je n'ai pas expérimenté le problème avec le test service (sur les sites de production). P>
Quelqu'un peut-il me donner des indices à ce qui cause cette soumission Ajax, et comment faire la reproduction localement? P>
C'est le JS avait l'habitude d'envoyer la demande: P>
{
"startedDateTime": "2015-12-11T12:26:58.018Z",
"time": 120066.61499999973,
"request": {
"method": "POST",
"url": "https://example.com/service.ashx?loc=area/subarea/",
"httpVersion": "HTTP/1.1",
"headers": [
... // removed for brevity
],
"queryString": [
{ "name": "loc", "value": "area/subarea/" }
],
"cookies": [
... // removed for brevity
],
"headersSize": 1163,
"bodySize": 48048,
"postData": {
"mimeType": "application/x-www-form-urlencoded; charset=UTF-8",
"text": ..., // removed for brevity
"params": [
... // removed for brevity ] }
},
"response": {
"status": 500,
"statusText": "Internal Server Error",
"httpVersion": "HTTP/1.1",
"headers": [
{
"name": "Date",
"value": "Fri, 11 Dec 2015 12:28:57 GMT"
},
... // removed for brevity
],
"cookies": [],
"content": {
"size": 54,
"mimeType": "text/xml",
"compression": 0
},
"redirectURL": "",
"headersSize": 305,
"bodySize": 54,
"_transferSize": 359
},
"cache": {},
"timings": {
"blocked": 120005.055999998,
"dns": -1,
"connect": -1,
"send": 1.0939999989932403,
"wait": 59.986000001008506,
"receive": 0.47900000172376167,
"ssl": -1
},
"connection": "7498"
4 Réponses :
Si la demande est traitée toujours en 2min, c'est une indication que votre côté serveur (nœud.js) ne finit pas la réponse correctement (avec RSP.end () ). 2 minutes est le délai d'attente par défaut sur le serveur express / noeud .
L'arrière-plan est une .NET Ashx. J'en ai expérimenté cela et ne croyez pas que ce soit un délai d'expiration de serveur. L'ASHX a un délai d'attente défini sur des heures et le fil continue d'exécuter même lorsque la réémission est terminée ou échouée. Quant à un délai d'attente JQuery, il n'y a pas de délai d'attente global et aucun délai spécifié pour cette instance non plus.
Même histoire ici. JQuery renvoie évidemment une demande après 120 secondes (le délai d'attente par défaut) si aucune réponse n'a été reçue par le client jusqu'à présent.
augmenter le délai d'attente comme dans: ne change pas le jeu. La demande restreint toujours après 2 minutes, bien que le client continue d'attendre toute réponse. Bien que le côté serveur soit capable de gérer ces deux demandes parallèle, les clients demandent des échecs sur la réponse valide de la première demande. . pas de solution pour le moment EDIT: It Actualy s'est avéré, que le navigateur est celui qui renvoie l'événement et que le comportement est entièrement conforme à Http / 1.1 spécifications. Et réellement le backend (node.js) fermé la prise après un délai d'attente de 120 secondes, comme le pointe des Jonasnas. La solution consistait à désactiver le délai d'attente à l'objet de réponse, comme dans:
Malheureusement, tous les autres recommandations (côté du navigateur) ici n'ont pas fonctionné pour moi. Cependant, il suffit de laisser la requête Ajax requiert immédiatement le travail:
Ceci peut être obtenu avec: P>
$.ajax("https://someurl/", {
...
timeout:1
...
});
déplacé Commentaire pour répondre à plus de visibilité. Notre numéro était un équilibreur de charge. Lorsque nous avons appelé le service d'API Web à partir d'Ajax via l'URL LB, nous obtenons le numéro de 120 secondes et les appels répétés au service, sans appels supplémentaires représentatifs du client. Lorsque nous appelons l'API via un nœud Server direct, supprimez l'équilibreur de chargement de l'équation, nous ne souffrons pas de la question. Si un équilibreur de charge est dans votre équation, recherchez si vous appelez directement au nœud de serveur. Si tel est le cas, engagez le support d'équilibreur de chargement.
En tant que solution de contournement intermédiaire, jusqu'à ce que LB est résolu, je retournerai le nom du nœud de serveur sur la page du client de la page de la page de la page dans un champ masqué et utilisez mon code JS pour construire une URL directe pour appeler le service.
Avez-vous vérifié si votre code (code AJAX) est-il appelé lorsque le résultat se passe-t-il ... vous pouvez ajouter un
console.log () STMT avant la demande Ajax et dans leBeforesend gestionnaires pour vérifier cela - si votre code envoie vraiment la deuxième requête, les messages seront connectés deux fois dans la console.L'étape suivante pourrait soit de mettre un point de rupture dans la ligne Ajax pour voir si elle est appelée deux fois et si vous voyez la trace de la pile pour voir comment / où le deuxième appel est initié à partir de ... ou vous pouvez utiliser le
console.trace () enregistrer pour voir la pile d'appelsJe suis certain que ce n'est pas ma demande Ajax à nouveau à nouveau dans le code. Pour une nouvelle soumission n'apparaît pas comme une demande distincte dans le profileur de réseau de chromes - ce que le code était simplement ré-exécuté. Beforesend n'est pas exécuté une 2e fois.
Oui .. Vous avez raison ... Dans ce cas, je ne pense pas que ce soit le code côté client qui le cause ... vous devrez relier votre code côté serveur ...
Je ne suis pas sûr de ce que le problème du serveur serait. La demande initiale continue d'exécuter même lorsque l'agent utilisateur a soumis à nouveau la demande. J'essaie d'épingler pour dire pourquoi la demande est soumise à nouveau.
Je suis confronté à un problème similaire aujourd'hui. Avez-vous pu résoudre ce problème lorsque vous avez fait face? Merci.
@ Drewwilliams Je connais également le même problème et je ne pouvais pas y remédier. Avez-vous eu au bas de cela? J'utilise webapi2 dans l'application web asp.net formulaires.
Salut tout le monde. Une chose à considérer, que j'ai découverte était la cause de notre problème. Nos serveurs Web sont une paire derrière un équilibreur de charge. Et nous appelions d'Ajax via l'URL LB. Lorsque nous avons appelé directement à un nœud serveur, cela a fonctionné bien. La LB provoque donc cette question pour une raison quelconque. Je vais creuser plus profondément dans cela pour le moment, mais devrait être suffisant pour vous aider à contourner le contournement, ou impliquer vos équipes de support de LB avec des traces de WireShark pour savoir pourquoi cela le fait et les changera.