views:

627

answers:

4

We've been using "Drip" to try and identify why pages with UpdatePanels in them tend to use a lot of client-side memory. With a page with a regular postback, we are seeing 0 leaks detected by Drip. However, when we add an update panel to the mix, every single DOM object that is inside of the update panel appears to leak (according to Drip).

I am not certain is Drip is reliable enough to report these kinds of things - the reported leaks do seem to indicate Drip is modifying the page slightly.

Does anyone have any experience with this? Should I panic and stop using Microsoft Ajax? I'm not above doubting Microsoft, but it seems fishy to me that it could be this bad.

Also, if you know of a tool that is better than Drip, that would be helpful as well.

+1  A: 

According to ASP.NET AJAX in Action, p. 257

Just before the old markup is replaced with the updated HTML, all the DOM elements in the panel are examined for Microsoft Ajax behaviours or controls attached to them. To avoid memory leaks, the components associated with DOM elements are disposed, and then destroyed when the HTMl is replaced.

So as far as I know, any asp.net ajax components within the update panel are disposed to prevent memory leaks, but anything else in there will just be replaced with the html received.

So if you don't have any asp.net ajax components in the target container for the response, it would be basically the same as an inner html replacement with any other js framework / ajax request, so i would say that it's just the how the browser handles this, rather than asp.net ajax causing this.

Also, while it may be "leaking", it may be by design, meaning that the browser might not have reclaimed the dom elements yet and released them. Also, drip might be causing those to leak, as it is attaching to those dom elements.

Darren Kopp
A: 

That's very likely. This was pretty much what we assumed (browser problem, not necessarily Ajax).

Our problem is now, with this application being accessed by many people via a Citrix environment, with each page continually creating DOM objects and not releasing them, the Citrix environment starts thrashing after some usage. I've seen similar complaints online (especially where you are dumb enough to access an Ajax website via Citrix), but it doesn't make me feel much better that this is the intended behavior.

I'm wondering now if anyone has come up with a clever workaround. We also have a client app where we are using the .NET BrowserControl to access these websites, rather than just straight IE7, so if anyone knows a secret API call (FreeStaleDomObjectsFTW()) we can utilize from that end of the stack, that would be useful as well.

Anderson Imes
A: 

you could attach to the pageLoading event of the PageRequestManager class and go through the panels updating property and remove the DOM elements in each.

Darren Kopp
A: 

Check out this article: http://www.codeproject.com/KB/ajax/jqmemleak.aspx