StrataFrame Forum » StrataFrame Application Framework - V1 » WebForms (How do I?) » Memory leak SF BO with DevExpress ASPxDataGridView

Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Fri, 15 Apr 2011 05:29:13 GMT

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

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Fri, 15 Apr 2011 05:29:13 GMT

I have debug and have temporary fix for this issue. I changed code in SF as below. What I tried to do is expose the instance of BusinessBindingSource used by WBBSEnumerator, then on page_unload, dispose it. At this moment, it doesn't solve my issue. I am in the progress to do more detailed testing to see if any impact to data editing inside gridview. Hope it helps SF team to speed up the permanent fix. Thank you

Public Structure WBBSEnumerator

Implements IEnumerator

Implements IEnumerable

#Region " Constructors "

''' <summary>

''' Initializes a new instance of this Enumerator structure.

''' </summary>

''' <param name="bo"></param>

''' <param name="start"></param>

''' <param name="count"></param>

''' <remarks></remarks>

Public Sub New(ByVal bo As BusinessLayer, ByVal start As Integer, ByVal count As Integer)

Me._BBS = bo.GetEnumerable(True, False)

Me._BusinessObjectEnumerator = Me._BBS.GetEnumerator()

Me._CurrentCount = 0

Me._MaxCount = count

Me._StartIndex = start

End Sub

''' More code

Public ReadOnly Property BBS() As BusinessBindingSource

Get

Return CType(Me._BBS, BusinessBindingSource)

End Get

End Property

End Structure

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Tue, 29 Mar 2011 07:00:07 GMT

any update?

Thank you

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 23 Mar 2011 20:45:21 GMT

I am totally agree that SF really helpful.

However, my customer and management want solution. Without that, everything is nothing for them.

Once again, very much appreciated on kindly support

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Peter Jones — Wed, 23 Mar 2011 16:11:02 GMT

Hi,

We use SF / DX combination for everything and have no problems but we don't use web forms. Anyway that's not why I'm posting. I just wanted to say that I think SF support is simply outstanding. Even though we don't use it much it is really nice to know such support depth is there.

Cheers, Peter

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Wed, 23 Mar 2011 10:14:38 GMT

Same issue, same problem. When a handler is not released, the object cannot be disposed. Thus you get a memory leak. That is why it is so important for all controls to work within the confines of the framework and interfaces used therein. In this example, the DevExpress controls that use attach to the IEnumerable interface are not releasing the handlers as expected. Thus, a memory leak. Again, we will see if there is something we can do to accommodate all 3rd party controls. But here is one thing that I have already proven. We can use a Custom BBS and an XtraReport with no memory leak whatsoever. This is a very common control and combination of tools used by SF users. Some of our largest users also use the XtraReports within massive applications. And if they were experiencing memory leaks like you have described, there would be mass chaos. The DevExpress web grid is another story, however, as most people take a different approach, as I have mentioned in previous dealings with your current issue.

Regardless, I would love nothing more than to find a solution on our side so we can get this behind us.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 23 Mar 2011 10:03:18 GMT

I hope I didn't defocus you, I need solution on memory leak which happen to ASP.NET XtraReport as well. I am not sure if the same root cause as ASPxGridView.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Wed, 23 Mar 2011 09:50:57 GMT

Which makes sense as this is a part of the IEnumerable interface to which the external controls bound to the WBBS or BBS can control the navigation of the object. However, it is their responsibility to add and remove the handler. The WBBS doesn't create the handler for the grid, the grid creates the handler. Thus the crux of the problem. We are going to see if there is a way for us, through reflection, to cut the ties to the control. But at the moment the control is hanging on to the WBBS, not the other way around.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 23 Mar 2011 09:42:21 GMT

OK.

Anyway, hope you found the solutions soon.

BTW, as I informed earlier, I sent the sample project to Microsoft support, they feedback that BO.List_Changed event is not released. You can refer back my previous messages. HTH

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Wed, 23 Mar 2011 08:23:23 GMT

I did say dispose, but I should have said release a handler. We are trying to determine what they are hanging on to. For the record, we are not going to get into a back and forth with DevExpress with you as the middle-man. We are still evaluating their grid to see if we can do anything that doesn't "break" all other environments. This is what happened the last time we made this accommodation for you.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 23 Mar 2011 06:26:13 GMT

May I know when should the GridView to dispose the WBBS's data? I asked DevExpress, with below reply:

[codesnippet]The datasource should not be disposed of during the pagelife cycle. The grid might use the datasource object even in the PreRenderevent handler. And if you dispose of the datasource somewhere in the code, thegrid will not be able to use it anymore.[/codesnippet]

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Tue, 22 Mar 2011 21:28:03 GMT

Thank you for your efforts.

Really need your help!!

Thank you

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Tue, 22 Mar 2011 08:30:53 GMT

We are going to look at it one more time, but like all previous examples that you have shown, the problem only seems to persist with the DevExpress grid. If the same thing is done with an Infragistics grid or the standard web grid, it works perfectly.

Looking back in our notes, this is the same thing that was mentioned on the previous 2 samples that were sent in. It looks the disposal does not fire through the DevExpress web grid...and ironically, this was due to an issue that you turned in after a point release of DevExpress over a year ago.

We are not through testing, but these are the current results.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Mon, 21 Mar 2011 21:39:43 GMT

May I know any update?

My customer keep calling us, and they expect this issue to be solved before 25/3/2011.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Thu, 17 Mar 2011 21:30:12 GMT

I totally agree with what you mentioned, "How come only we hit this issue?!!?!?!" Just like last time, only we hit thread-safe issue, transaction issue and etc. At last only found that

1. Thread-safe - bug

2. Transaction - Only happen if using ad-hoc CRUD for, working fine for SP

3. Memory leak (1st reported) - DevExpress and SF integration issue

My mgmt also asking since so many developers are using SF and DevExpress UI why don't they hit issue as us? I also don't know how to answer.

Anyway, if you think is our environment issue, please post me question, or I can arrange remote access for you. We can do anything for you, we just need solution!!! Memory leak issue has brought our company into very very worst market position at this moment.

Much appreciate for your help

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Thu, 17 Mar 2011 08:57:08 GMT

Well, like I said, we have so many people that use XtraReport and DevExpress and don't experience these issues. So there is some underlying design issue or environmental issue that you guys seem to always be up against. But at any rate, we will look at the sample that you post to see if there is something framework related.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Thu, 17 Mar 2011 04:49:24 GMT

I have posted my sample project

Testing DB

Sample project

I also attached screenshot of ANTS profiler which shown the instances of BO keep increasing for each refresh.

Screenshot

Please advice ASAP

Thank you

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 16 Mar 2011 19:40:25 GMT

BTW, I don't think we have very unique environment as I just use simple BO with XtraReport. Also, for the reporting tool, we never do any custom code to it as well. Just a simple listing. Anyway will upload the sample as soonest.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 16 Mar 2011 19:35:56 GMT

[quote][b]Trent L. Taylor (3/16/2011)[/b][hr]We will look at your project, Chan. I would be very surprised at this point if there was in fact a memory leak. We have hundreds of customers that use both the XtraReports and the Dev Grid. But there can always be a certain property or environment that causes a particular issue. So we can take a look and go from there. But from the sound of it, you still have not heeded my advice on creating a custom control. This is a bit disappointing, though, because it seems like you have a very unique and custom environment and you are trying to squeeze a 3rd party control to fit you very specific and custom needs which I think is part of your problem.[/quote]

Hi,

My company is really willing to do so, but we lack of experience on this at this moment. Beside, we are busy to solve some other issues before this. That is the reason we would like to have SF team to send us built custom control so that we can use it straight away or at least some reference.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Wed, 16 Mar 2011 08:38:55 GMT

We will look at your project, Chan. I would be very surprised at this point if there was in fact a memory leak. We have hundreds of customers that use both the XtraReports and the Dev Grid. But there can always be a certain property or environment that causes a particular issue. So we can take a look and go from there. But from the sound of it, you still have not heeded my advice on creating a custom control. This is a bit disappointing, though, because it seems like you have a very unique and custom environment and you are trying to squeeze a 3rd party control to fit you very specific and custom needs which I think is part of your problem.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Tue, 15 Mar 2011 21:55:48 GMT

After so many discussion, we are in the progress to change our application to limit # of records to be retrieve and also added search feature to all listing page.

However, now we are facing memory leak issue in DevExpress XtraReport (ASP.NET) also. We are using WBBS to bind our BO to report. It only contains few records. When I keep refresh the report, I see the BO (datasource) instance keep increasing. From ANTS profiler, it is referenced by SharedDataTable therefore unable to be released.

My developer is in the progress to prepare sample project.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Trent L. Taylor — Mon, 10 Jan 2011 10:30:49 GMT

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.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Ivan George Borges — Wed, 22 Dec 2010 12:15:24 GMT

[quote]may i know no update mean what?haven't test, don't know the root cause yet, don't know solution yet or no plan to fix it?[/quote]

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

[quote]My customers just can't keep waiting endless. We need at least a workaround.[/quote]

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.

[quote]This issue has been reported for more than a month, hope SF team understand our difficulty as well.[/quote]

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

Cheers.

RE: Memory leak SF BO with DevExpress ASPxDataGridView

ChanKK — Wed, 22 Dec 2010 10:07:24 GMT

any timeline?

may i know no update mean what?

haven't test, don't know the root cause yet, don't know solution yet or no plan to fix it?

My customers just can't keep waiting endless. We need at least a workaround.

This issue has been reported for more than a month, hope SF team understand our difficulty as well.

Thank you

RE: Memory leak SF BO with DevExpress ASPxDataGridView

Ivan George Borges — Wed, 22 Dec 2010 04:27:03 GMT

No Chan, not yet.