DataSource references to components and memory in IE?

[stonebranch1]

I know when you call ds.updateCaches it "Causes any components using this DataSource to be notified of changes". Does this mean the DataSource has some kind of reference to the all the components currently using it as its DataSource?

Reason I ask is we are having a memory issue, but only in IE (IE 11 is what we have tested). Chrome and Firefox work fine. Using the F12 Developer Tools in IE 11 and doing some profiling, it shows that our ListGrids are still in memory even though we have called destroy() on them. Each time I load another ListGrid and then replace it causing the destroy to be called on it, it still shows up in the F12 profiling.

I then tried a test where I called destroy on the DataSource and then all those ListGrids were gone from the profiled memory.

Is there anything you recommend I should try or do?

Thanks.

SmartClient Version: v9.1p_2014-09-11/Pro Deployment (built 2014-09-11)

[stonebranch1]

I have not been able to reproduce this in a stand-alone test so I am trying to think and look to see if there is something we maybe doing that is causing this behaviour...

Any suggestions would be greatly appreciated.

[Isomorphic]

DataSources do have two-way links to their ResultSets and ResultTrees, but these are of course cleaned up on destroy().

Since this problem is IE-only, really the most likely explanation is that your use of IE Developer Tools is actually what's creating the issue! Have you tried reproducing with the Developer Tools closed, the Developer Console closed, and Track RPCs disabled?

[stonebranch1]

OK. Thanks for the information.

Yes the problem does occur outside the use of the tools. Basically loading up IE and using our application causes the memory to constantly grow without any Tools or Console having ever been opened.

I then used the IE Developer Tools to try and track down what things may not be getting cleaned up and that is when I saw our ListGrids hanging about for some unknown reason.

We have made sure all the destroy methods are getting called which they appear to be. We will continue to try and track it down...

Thanks.

[Isomorphic]

We've seen IE Developer Tools introduce false leaks before, so we'd recommend:

1. Only open them after you've already caused memory to increase while the tools were closed

2. If the tools seem to indicate any specific leak, verify it's real with an alternative approach where the tools have never been opened. For example, in this case, you could use JavaScript to see if the ListGrids are still around (one approach would be a SmartGWT button that uses JSNI when clicked)