FileUltimate Memory Leak
Problem reported by Douglas Hartley - November 30 at 7:34 AM
Not A Problem
We recently started using FileUltimate, after deploying to production with version 6.0 it appears to have caused a memory leak. We then upgraded to the latest version 6.3 and re-deployed but it has not fixed the memory leak. We've been able to track down the source of this though our dump file to system.strings with a call stack though "FileManagerState (GleamTech.FileUltimate.AspNet.UI)" and "ComponentEventManager (GleamTech.AspNet.UI)" on the EventHandler <FileManagerUploadedEvenetArgs>.
 

This memory leak is not linear, it ramps up then holds steady then ramps up more. Ex: memory is at 400MB then ramps up to 600MB then holds at 600MB for a bit then ramps up again to 750MB, after 24 hours its over 7GBs of memory. I have dump file, if you will need that dump or if there is any more information you'll need to track down this issue just let me know.

Thank you,
Douglas Hartley

1 Reply

Reply to Thread
0
Cem Alacayir Replied
Employee Post
In the ServerEvents page of the example project, there is a comment warning about this:
//Attached event handlers should be static methods because they are raised out of the context of the host page.
//If instance methods are attached (eg. an instance method of Page class), this would cause memory leaks. 
 
Please define the event handler as static (or Shared in VB.NET):
private static void FileManagerDownloaded(object sender, FileManagerDownloadedEventArgs e)
 
Actually, the “static” requirement is specific to FileManager events because it has to maintain state between requests. After FileManager is rendered, your host page is rendered and already finished executing so the context is lost (Page class is probably disposed). So when you click “Download” button you are no longer in the same request, i.e. in the same context of your host page. You are in a new request (http handler). That’s why you need static events to be reliable. FileManager is a complex control so you cannot simply have “postback” like a simple button control.
 
Fortunately in static context, you can still access Session object via
HttpContext.Current.Session
 
HttpContext.Current also provides all other properties same as Page.Context
So make your event handler static, i.e. if it needs request objects like Session then use HttpContext.Current to access them. Don’t forget once you are in a static method, you cannot call owner class’ instance methods.

Reply to Thread