Hi,
I think I've discovered what appears to be a memory leak when using the ResourceGroupDescription to group appointments on the schedule control by a ResourceType.
When Appointment objects are created it looks like it is hooking into a PropertyChanged event, but when the AppointmentsSource is cleared or replaced, the appointment objects are never released.
This becomes a problem when one has the schedule control set to refresh every minute or when using the VisibleRange changed command to load in appointments on demand.
The old appointment objects are never getting released so there could be thousands built up in memory over the course of a day.
When I removed the ResourceGroupDescription from the GroupDescriptionsSource the appointments were getting released from memory when my VisibleRangeChangedCommand executed.
Can you confirm please.
16 Answers, 1 is accepted
Rank 1
I have uploaded a sample project to this location to demonstrate the issue:
Download: http://www.fileserve.com/file/d6MZY2A/ResourceGroupDescriptionLeak.zip
When I use the following line in my MainPage.xaml:
<telerik:ResourceGroupDescription ResourceType="Employee" />The Appointment objects never get released from memory and continue to build up.
Clicking the Refresh button at the top of the sample window several times (10 - 20) and taking a snapshot with a memory profiler will show the Appointment instance count continually increase.
If you remove the above line from the XAML file and repeat the same steps you can see the instance count stays steady and old appointment objects are being released from memory.
Thank you for reporting us this memory leak. I investigated the issue you are observing and it seems that the memory leak exists always when the ScheduleView is grouped (it doesn't matter is it grouped by Resource or Date) and the source of the problem is the Silverlight ListCollectionView. I logged the issue in PITS and you can track its progress there.
Your Telerik Points were updated for your cooperation.
Miroslav Nedyalkov
the Telerik team
Rank 1
Unfortunately we don't know for any work-around for this problem and as the issue is in connected with the Silverlight ListCollectionView it is very hard to either fix the problem or to find an work-around for it.
Regards,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
Rank 1
This issue is rather painful for us though, one of our customers is using our application in a Citrix environment where users tend to keep the application running for a long time. This means the memory usage starts to add up over time, so I do need some way to resolve/work around this.
I completely understand how painful could be a memory leak especially in a long-living application, but as this problem is very deep in the ScheduleView control it is very hard to think of a work-around for it. I also cannot give you a concrete time frame when we will be able to work the problem around in our code, but we will be looking into it right after the upcoming Q3 2012 release which is expected to be the next week.
I'll write you back as soon we have any progress on the issue.
Kind regards,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
Rank 1
If you manage to work around this somehow an internal build would be appreciated.
In the mean time, does this relate the way the CollectionView deals with CollectionChanged events? It that case we might be able to work around this by using a collection which doesn't do change notifications for our appointments. This would mean refreshing manually whenever something happens, so before I try this I'd like to know if it would help.
Rank 1
We couldn't find a work-around for the issue, but we will try to estimate the efforts needed to change the ScheduleView and fix the issue. As the problem is very deep inside the control and fixing it will affect its architecture, we cannot easily estimate the time we need to fix it. We will look in the problem and I'll write you back when we know when the issue will be fixed.
Regards,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
Rank 1
This basically is out flow on VisibleRangeChanged right now:
- Call RemoveAll() on the Appointments and SpecialTimeSlots collections.
- Call RemoveAll() on the GroupDescriptions collection and Recreate the GroupDescriptions.
- Load the new data.
- Add new Appointments and SpecicialTimeSlots to the existing collections.
This seems to at least minimize the the amount of memory leaking away.
There is some stuff I learned along the way.
- Don't call Clear() on your appointments collection (and SpecialTimeSlots!), use RemoveAll() from the Telerik CollectionExtensions instead (or remove all items manually). Somehow a Clear() of an ObservableCollection doesn't trigger the cleanup code, where Remove does(). Alternatively you could use a List instead of an ObservableCollection, which seems to have the same effect.
- The ResourceGroupDescription PropertyChanged event keeps the references to the Appointments alive. I did build a customized version of the RadScheduleView, which added a function to clear the PropertyChanged event of the ResourceGroupDescription, calling this when the reloading the appointments did the trick as well. I opted for recreating the GroupDescriptions because this was the simplest workaround. But as a long term fix it seems to me it should be possible to explicitly remove the PropertyChanged event from the ResourceGroupDescription whenever an Appointment gets removed from the Appointments collection.
Using JustTrace I still see a few Appointments floating around which I cant really account for, but this doesn't seem to grow that much over time. There might be a small leak left, but perhaps it's just a side-effect of UI virtualization. At least the memory usage doesn't go through the roof anymore.
P.S. So far I've only tested what happens when scrolling through date in a DayView. I will test other usages, so more issues might pop up.
Thank you for sharing your work-around for this problem. This will give some more time for solving the issue.
Greetings,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
We investigated this memory leak further and found out that the best work-around for the problem is just to remove all items before either changing the AppointmentsSource or the resources. You don't need to recreated the GroupDescriptions to work-this-problem-around.
I confirm that the bug is in the implementation of the ListCollectionView in Silverlight - once initialized, the internal CollectionView group never detaches from its descriptior's PropertyChanged event. We will consider dropping the CollectionView from the RadScheduleView in future, but for now I would suggest you to use the work-around.
Regards,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
Rank 1
This should solve the problem. Do you still experience issues? If so, please share them with us, so that we can research them and eventually find another work-around, if one exists.
Thank you for your involvement.
Regards,
Konstantina
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
Rank 1
Hello,
Is this memoryleak also happen in RadScheduleView for WPF ?
The issue discussed in this forum thread is related to the ListCollectionView implementation for Silverlight (check this post). So you shouldn't observe the same issue for WPF. However if you have observed something similar, I would like to ask to open up a new support ticket and provide some more details regarding the exact scenario and a sample project if possible.
If you have any other questions, please let us know.
Regards,
Kalin
Telerik