Multiple RadProgressContext in Application Object

[Brent Miller]

I dumped out the contents of my asp.net application state and noticed many RadProgressContext instances.

Here’s a sample of the output I created while dumping the application state:

HttpContext.Current.Application[key]	HttpContext.Current.Application[key].ToString()
RadProgressContexta994ac27-7029-4afc-aba5-f71d1f53636d	Telerik.Web.UI.RadProgressContext
RadProgressContext9abbf6cc-983f-466d-bf0c-08d3144e0cc5	Telerik.Web.UI.RadProgressContext
RadUploadContext9abbf6cc-983f-466d-bf0c-08d3144e0cc5	Telerik.Web.UI.RadUploadContext
RadProgressContextb154df9a-33f7-4f30-b5ba-c27887fb83f1	Telerik.Web.UI.RadProgressContext
RadProgressContext0eaa8757-91ec-4dcf-8cd1-f6d8bf36bc52	Telerik.Web.UI.RadProgressContext
RadUploadContext0eaa8757-91ec-4dcf-8cd1-f6d8bf36bc52	Telerik.Web.UI.RadUploadContext

That is a sample, there are lots more of these. Does this indicate an issue? Do I need to do something to clean this stuff up?

 Thanks,

[T. Tsonev]

Hello Chris,

Please, excuse me for the delayed response.

These objects should be cleaned up automatically. We did some testing, but we were unable to reproduce the problem - the context was cleared after each request completed:



(this is after 10 uploads)

The tests were done with the standard RadUploadHttpModule. Are you, by chance, using the SPRadUploadHttpModule in Sharepoint? We might need to do some additional testing if this is the case.

We would appreciate more information about your application. A running sample that reproduces the issue will be ideal. But we can start by looking at the current web.config.

The good thing is that these objects are very small and the application can tolerate quite a few of them. Of course, it's a problem if they stay in memory indefinitely and we'll be looking forward to solve it.

Sincerely yours,
Tsvetomir Tsonev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[Randy Wilkinson]

I have a similar issue only I have 14220 of these objects and roughly 4.4 million
of Telerik.Web.UI.Upload.RequestField and the same amount of Telerik.Web.UI.Upload.FieldHeaderInfo
at a site that does high volumes of uploads using your upload control.
I am on version 2008.03.1314.35.
Is this memory leak a known issue? I am working on reproducing locally.

DOMAIN(0000000006C1A970):HANDLE(WeakLn):2ee1230:Root:00000000ff6a79f0(System.Web.NativeFileChangeNotification)->

00000000ff6a79b8(System.Web.DirMonCompletion)->

00000000ff6a7638(System.Web.DirectoryMonitor)->

00000000ff6a7678(System.Collections.Hashtable)->

00000000ff6a76d0(System.Collections.Hashtable+bucket[])->

00000000ff6a7830(System.Web.FileMonitor)->

00000000ff6a7888(System.Collections.Specialized.HybridDictionary)->

00000000ff6a7908(System.Collections.Specialized.ListDictionary)->

00000000ff6a7938(System.Collections.Specialized.ListDictionary+DictionaryNode)->

000000014f56c488(System.Web.FileChangesMonitor)->

000000014f56c618(System.Collections.Hashtable)->

000000012f9ffb48(System.Collections.Hashtable+bucket[])->

000000014f5af390(System.Web.DirectoryMonitor)->

000000014f5af3d0(System.Collections.Hashtable)->

000000015f56c678(System.Collections.Hashtable+bucket[])->

000000014f603428(System.Web.FileMonitor)->

000000014f603480(System.Collections.Specialized.HybridDictionary)->

000000014f603500(System.Collections.Specialized.ListDictionary)->

000000014f603530(System.Collections.Specialized.ListDictionary+DictionaryNode)->

000000014f605450(System.Collections.Specialized.ListDictionary+DictionaryNode)->

000000014f6150d0(System.Collections.Specialized.ListDictionary+DictionaryNode)->

000000014f605540(System.Web.HttpApplicationFactory)->

000000014f605738(System.Web.HttpApplicationState)->

000000014f605808(System.Collections.Hashtable)->

000000020c641e88(System.Collections.Hashtable+bucket[])->

0000000119aad3a0(System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry)->

0000000119aad2e8(Telerik.Web.UI.RadUploadContext)->

[Genady Sergeev]

Hi Randy Wilkinson,

We are not able to reproduce the problem on a sample project and in general we are not aware of memory leaks issues with RadUpload. Do you have any progress into reproducing this on a sample project?

Regards,
Genady Sergeev
the Telerik team

[Randy Wilkinson]

I have tracked this issue down to a Page.Response.Redirect({url},true) in the postback of a page that contains the RadUpload control and a file has been uploaded.  I have not had time to produce a sample project for you, but this information should be sufficient for you to do that. So you are correct in saying that there is no leak when the request is completed but a redirect of this type ends the thread execution and therefore doesn't complete. I think the bigger problem is that the module thinks that another upload is taking place during a simple postback. It seems wrong that these objects are created and destroyed in every postback after an upload.

My initial thoughts around fixing this are to put the radupload control and the surrounding code in an iframe to prevent the module from creating these objects in postbacks of the main form.

[Genady Sergeev]

Hello Randy Wilkinson,

Thank you for the report. We will research the issue and write a follow up by the end of the upcoming week.

Best Regards,
Genady Sergeev
the Telerik team

[Randy Wilkinson]

Since I never got a response here, I thought I would post my own update.

I was able to prevent this memory leak by putting the entire uploading module of our application in an IFrame (like a RadWindow). This prevented the RadUpload framework from executing code during the postbacks of the main page, which also prevented the creation and stranding of these objects in cache during a page redirect.

Randy

[Genady Sergeev]

Hello Randy Wilkinson,

Thank you for sharing this answer with the community. I've updated your telerik points accordingly.

Regards,
Genady Sergeev
the Telerik team