Microsoft ASP.NET Ajax provoque-t-il des fuites d'objets DOM ?

Question

Nous avons utilisé "Drip" pour essayer d'identifier pourquoi les pages contenant des UpdatePanels ont tendance à utiliser beaucoup de mémoire côté client.Avec une page avec une publication régulière, nous constatons 0 fuite détectée par Drip.Cependant, lorsque nous ajoutons un panneau de mise à jour au mélange, chaque objet DOM qui se trouve à l'intérieur du panneau de mise à jour semble fuir (selon Drip).

Je ne suis pas certain que Drip soit suffisamment fiable pour signaler ce genre de choses - les fuites signalées semblent indiquer que Drip modifie légèrement la page.

Est-ce que quelqu'un a de l'expérience avec ça?Dois-je paniquer et arrêter d’utiliser Microsoft Ajax ?Je n'hésite pas à douter de Microsoft, mais cela me semble louche que cela puisse être le cas. ce mauvais.

De plus, si vous connaissez un outil meilleur que Drip, cela serait également utile.

Answer 1

Selon ASP.NET AJAX en action, p.257

Juste avant que l'ancien balisage ne soit remplacé par le code HTML mis à jour, tous les éléments DOM du panneau sont examinés pour détecter les comportements Microsoft Ajax ou les contrôles qui leur sont attachés.Pour éviter les fuites de mémoire, les composants associés aux éléments DOM sont supprimés, puis détruits lors du remplacement du HTMl.

Donc, pour autant que je sache, tous les composants ajax asp.net dans le panneau de mise à jour sont disposés pour empêcher les fuites de mémoire, mais tout le reste sera simplement remplacé par le code HTML reçu.

Donc, si vous n'avez aucun composant ajax asp.net dans le conteneur cible pour la réponse, ce serait fondamentalement la même chose qu'un remplacement HTML interne par n'importe quelle autre requête framework js/ajax, donc je dirais que c'est juste le comment le navigateur gère cela, plutôt que asp.net ajax qui en est la cause.

De plus, même s'il peut y avoir une « fuite », cela peut être intentionnel, ce qui signifie que le navigateur n'a peut-être pas encore récupéré les éléments dom et ne les a pas publiés.En outre, les gouttes peuvent provoquer des fuites, car elles se fixent à ces éléments dom.

Answer 2

C'est très probable.C'est à peu près ce que nous pensions (problème de navigateur, pas nécessairement Ajax).

Notre problème est maintenant que cette application est accessible à de nombreuses personnes via un environnement Citrix, chaque page créant continuellement des objets DOM et ne les publiant pas, l'environnement Citrix commence à se débattre après une certaine utilisation.J'ai vu des plaintes similaires en ligne (en particulier lorsque vous êtes assez stupide pour accéder à un site Web Ajax via Citrix), mais cela ne me rassure pas beaucoup que ce soit le comportement prévu.

Je me demande maintenant si quelqu'un a trouvé une solution de contournement intelligente.Nous avons également une application client dans laquelle nous utilisons .NET BrowserControl pour accéder à ces sites Web, plutôt que simplement IE7, donc si quelqu'un connaît un appel d'API secret (FreeStaleDomObjectsFTW()) nous pouvons utiliser à partir de cette extrémité de la pile, ce serait également utile.

Answer 3

vous pourriez joindre au Événement pageLoading de la classe PageRequestManager et parcourez les propriétés de mise à jour des panneaux et supprimez les éléments DOM dans chacun.