Hi,

I am facing memory leak problem when using SF BusinessObject and DevExpress ASPxDataGridView.

I have simple test project, which only has one BO, bind to ASPxDataGridView. It does nothing complicated, just load all records in Page_Load if not IsPostBack.



I found that, the memory usage would become double when I just "refresh" the page. I also used dotTrace profiler and found that # of BO instances keep increasing. I suspect it is the same issue with the post http://forum.strataframe.net/Topic20903-8-1.aspx.



I have prepared sample project and the dotTrace memory profiler files for your reference. MemoryLeak1.dtm is first load memory snapshot and MemoryLeak2.dtm is 2nd snapshot after refresh.



As the file size > 30MB, please download it from http://www.visualsolutions.com.my/blog/chankk/WebApplication6.zip



Hope you could get back to me as soon as possible! It is very urgent!



Thank you

hi

None of the alternatives. It just means I haven't been updated on it.



That is understandable, but I need to remind you, as I have done before, that this has been considered an ASP.NET issue by your other third party grid vendor, which even openly stated that it wouldn't fix it, and what our developing team will try is to find you a workaround, if possible. All I know is that it is on their list.



Yep, we all do and appreciate your business, and will try to help you as soon as possible, I am sure about it.

Cheers.

I thought that I close out this post as email was used to work through this process. 

There were a lot of posts here and so it is just a matter of time before people look back here for a solution.  In short, we have gone through this thoroughly and sufficiently proven that StrataFrame doesn't have a memory leak.  There was, however, a valid issue that this customer was dealing with in regards to a memory leak and a DevExpress grid.  Below are two memory profiles, one with a DevExpress grid and another with a standard GridView:

DevExpress Web Grid Memory Profile

(Download the attachment for a better look)

The DevExpress web grid does have many objects still in memory as part of this process.  In most cases, this would probably not cause an issue as the "leak" was negligible.  But if you are retrieving a very large data set and dealing with many records, then this could be an issue.  Also, the more records that are in the data set, the DevExpress.Web.ASPxClasses (Display Classes) that will be created, thus increasing memory size.  This not not a fault of DevExpress, but more of an attribute to the complexity and functionality of their control.

GridView Memory Profile

(Download the attachment for a better look)

In this example, the same test was performed.  A new property called AutoDisposeHandlersAndObjects was added to the WebBusinessBindingSource that allows the control to clean up automatically.  Though this can be used on the GridView and several others that have been tested (i.e. Infragistics), this will not work with the DevExpress Web Grid as the way that they enumerate the underlying data source prevents certain disposals from taking place, though the instance never grew past 1 BBS in our testing.  That said, you can see that in the GridView test, there are no BBS references remaining and the environment is much cleaner.  This is not a criticism of DevExpress web grid by any means, just an observation, as the GridView doesn't have the "pre-built" logic the DevExpress grid does.  But the BBS can be released as part of the process.

Closing
In closing, we are not saying that there is a bug in the DevExpress Web Grid, just noting some possible issues that you may run into during development.  If there were a bug, it would be in ASP.NET most likely anyway.  If nothing else, there could be some philosophical differences here in dealing with large data sets within a grid and/or how to enumerate the underlying data source.  DevExpress has many great tools and products and we highly recommend them, but like any development cycle, each project should be evaluated to see if a particular control will meet the needs for specific intents and purpose.  So this is just to make you aware of any possible issues that may be encountered when using a StrataFrame BBS and a DevExress Web Grid.