Has the memory leak issue for Gridweb referred to in <A href="https://forum.aspose.com/t/86267</A> been resolved? If so, what is the resolution?</P>
<P>I have an application in production that is leaking memory, requiring a recycle of the application pools at least twice a day.</P>
<P>I am loading files from excel templates. Using a memory profiler, I've found that every call to ImportExcelFile or RunAllFormulas causes an arraylist to be left in memory in the Aspose.Excel.Webformula.Lns namespace and a collection to be left in memory in Aspose.Excel.Webformula.Lns.collections.impl namespace. A new copy is created and remains in memory with each page load or postback.</P>
<P>The .Net size of the undisposed objects is not large, but based on heap analysis they seem to be references to native objects that are not disposed & released. Since the .Net objects don't seem to be releasing the native objects, the .Net objects are always live instances and never release the much larger native objects.</P>
<P>I have verified that these objects are never garbage collected (most likely because they are not releasing their native objects). GC handles are created by the CLR, but never are used. Even 26 hours after the session ends, the objects are still in memory on a VERY active server. In that period, the garbage collector ran over 600 times and released everything but these objects (as well as some other application-level objects that always stay in memory in aspnet_wp.exe).</P>
<P>The sample program provided in the post referenced above can be used to test this condition. Using an excel spreadsheet with a LOT of worksheets and formulas makes it very apparent what is going on.</P>
<P>Can a hotfix be issued to help with this so that when the grid is disposed all resources are disposed? It's important to note that this is not a test system - this system is in production and has been for 6 months. The problem became very troublesome recently as users added some very complex spreadsheets with a lot a formulas in them. Alternately, is there something I can do the manually dispose of these objects when the control is disposed? For example, the style attributes also do not dispose properly, but I can manually force them to do so by adding Gridweb.ViewTableStyle.Dispose() and Gridweb.ViewTableStyle=null in my code. Can something similar be done with the formulas?<FONT size=2></P></FONT>
<P>One note: I'm not sure if Gridweb uses VSTO, but having used VSTO extensively I know that it's very important to dispose of objects (or better yet allocate them through the "using" keyword) when in VSTO - otherwise the com objects in the underlying native office dlls aren't properly released.
A prompt reply would be greatly appreciated!
Hi,
Thanks for sharing us some details.
We will get back to you soon.
Thank you.
One other thing that may be of use. The spreadsheets that caused the problem to be unbearable have many formulas that have cross-worksheet references (e.g. a formula on Sheet 2 refers to cells on Sheet 1).
Again, not having the code I don't know if this makes a difference, but I thought it may be another clue to the puzzle.
Hi,
Well, Aspose.Grid is independent of office automation, the control does not use VSTO APIs. After investigating your issue thoroughly and conducting several tests, we found an issue regarding GridWeb's formula calculation engine. There is also an instantiation problem regarding TableItemStyle. We will fix them in later/future versions.
Thank you.
I'm glad you were able to identify the issues.
Since I am having severe problems in a production environment right now, is there a workaround I can implement, or can a hotfix be made available within the next few days?
Thank you for your help.
I don't want to seem too pushy, but I need to know if I can either get a fix or if you have a workaround I can implement. If I can't get this fixed I will need to look into alternatives because I can't have our web site crashing several times a day.
Please let me know if there is anything you or I can do.
Thanks!
Hi,
We will get back to you soon.
Thanks for being patient!
Hi,
First of all, please check your value of SessionMode property. If it is session, the relative objects for GridWeb will be kept in Asp.NET Session. So, if your session is still alive, the relative objects will not be released rather they will be released by IIS at sometime. When many users are online, their sessions will be alive too, and consequently huge memory are being used.
We recommend a solution that you should change to SessionMode to ViewState, and invoke GC.collect() manually in the background thread timing. We have tested this solution and it works fine.
Please try the following code:
First, add a new background thread class to the project.
public class BackgroundThread
{
private static Thread thread = null;
public static void start()
{
thread = new Thread(new ThreadStart(BackgroundThread.doGC));
}
private static void doGC()
{
while (true)
{
// please reset a proper interval.
Thread.Sleep(60 * 1000);
GC.Collect();
GC.WaitForPendingFinalizers();
}
}
public static void trigger()
{
if (thread.IsAlive)
{
thread.Abort();
}
else
{
thread.IsBackground = true;
thread.Start();
}
}
public BackgroundThread()
{
}
}
Then, find Global.asax file in your project, and modify the Application_Start method as following:
void Application_Start(object sender, EventArgs e)
{
BackgroundThread.start();
BackgroundThread.trigger();
}
When the application starts, the GC will work every 1 minute. You may find a proper interval for your need and change it accordingly.
Thank you.
Thank you for the update.
The only issue I have with this solution is that the application requires updating of the calculations as the user makes changes (EnableAJAX=true). This does not seem to work when SessionMode=ViewState.
Is there any other way around this? I cannot change the application to have the user wait on a full postback to update their calculations. Alternately, is there a way to have AJAX updating work with SessionMode=ViewState?
Thanks for your help.
Hi,
When SessionMode = ViewState, ajax is not able to post back the data in ViewState hidden field. So, the control cannot get full data and will not calculate the formulas. It works fine only when SessionMode = Session.
For your need, we suggest that you should change SessionMode back to Session and configure the application’s session state.
Please check the “sessionState element” topic in MSDN first. You may change your configuration into StateServer or SQLServer. The following steps can be used for the StateServer in our situation:
-
Start ASP.NET State Service in Services Management.
-
Add or modify the sessionState configuration in system.web section of web.config file. Our state server is running in the same system with IIS. You may deploy it into other machine. i.e…,
<sessionState mode=“StateServer”
stateConnectionString=“tcpip=127.0.0.1:42424”
cookieless=“false” timeout=“20” />
-
Modify the value of SessionMode property into Session in the pages and recompile the project.
-
Keep the background thread which invokes GC.collect() timing.
-
Start to run the application.
The memory leak issue does not appear any more, and the ajax works fine.
Thank you.
While this solves the memory problem, with this solution the cell formatting is lost on all worksheets except for the one that is first loaded on a multiple-tab worksheet.
Is there a workaround for this problem?
Also, performance is fairly bad, which I expected since the session is getting serialized.
When will a real fix be available instead of a workaround????
Hi,
We have tested your mentioned issues with an excel file whose size is 292k and contains 17 worksheets, 15000 cells and 2500 formulas. We set the session storage with StateServer. We find the performance issue is caused by serialization of session. We’ll enhance it in a few days. And, the lost styles issue was not found. We tested with v<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />2.0.1.2005. Please try the latest fix (attached) to test the lost styles issue.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Could you provide more detailed information as following?
1. Your file size, number of worksheets, formulas and cells etc.
2. You told that “Even 26 hours after the session ends, the objects are still in memory on a VERY active server. In that period, the garbage collector ran over 600 times and released everything but these objects (as well as some other application-level objects that always stay in memory in aspnet_wp.exe)”. When the session ends, is there any other user online? And what value is set with your session timeout?
3. The max number of your online users.
Thank you.
Hi,
Please try the attached version v2.0.1.2006, we have optimized the memory usage of styles in this version. The performance of serialization has also been enhanced a bit.
Thank you.