Memory Leak when using ResourceGroupDescription

17 posts, 0 answers
  1. Brendan
    Brendan avatar
    7 posts
    Member since:
    May 2009

    Posted 10 Feb 2012 Link to this post

    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.

  2. Brendan
    Brendan avatar
    7 posts
    Member since:
    May 2009

    Posted 10 Feb 2012 Link to this post

    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.

  3. DevCraft banner
  4. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 16 Feb 2012 Link to this post

    Hi Brendan,

    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.

    Regards,
    Miroslav Nedyalkov
    the Telerik team
    Sharpen your .NET Ninja skills! Attend Q1 webinar week and get a chance to win a license! Book your seat now >>
  5. Jakkie Esschert van den
    Jakkie Esschert van den avatar
    61 posts
    Member since:
    Sep 2009

    Posted 05 Oct 2012 Link to this post

    Looking at the PITS issue this hasn't been resolved yet, is there any workaround to avoid this leak without loosing the grouping?  
  6. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 08 Oct 2012 Link to this post

    Hello Jakkie,

    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.

  7. Jakkie Esschert van den
    Jakkie Esschert van den avatar
    61 posts
    Member since:
    Sep 2009

    Posted 10 Oct 2012 Link to this post

    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. 

  8. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 11 Oct 2012 Link to this post

    Hello Jakkie,

    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.

  9. Jakkie Esschert van den
    Jakkie Esschert van den avatar
    61 posts
    Member since:
    Sep 2009

    Posted 15 Nov 2012 Link to this post

    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.

  10. Oscar Wahlen
    Oscar Wahlen avatar
    33 posts
    Member since:
    Mar 2010

    Posted 19 Nov 2012 Link to this post

    I hope this gets sorted out real soon because we are handling large amounts of appointments (several hundreds) at once.
  11. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 19 Nov 2012 Link to this post

    Hello,

    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.

  12. Jakkie Esschert van den
    Jakkie Esschert van den avatar
    61 posts
    Member since:
    Sep 2009

    Posted 03 Dec 2012 Link to this post

    I've done some digging into this and found a few things. I'm not 100% sure this solves all issues, but I seem to have a fairly stable situation right now.

    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.
  13. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 05 Dec 2012 Link to this post

    Hi Jakkie,

    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.

  14. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 27 Dec 2012 Link to this post

    Hello Everybody,

    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.

  15. Mattias
    Mattias avatar
    15 posts
    Member since:
    May 2011

    Posted 26 Sep 2013 Link to this post

    Does the workaround solve the entire problem with the memory leak?
  16. Konstantina
    Admin
    Konstantina avatar
    2332 posts

    Posted 01 Oct 2013 Link to this post

    Hello Mattias,

    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
    TRY TELERIK'S NEWEST PRODUCT - EQATEC APPLICATION ANALYTICS for SILVERLIGHT.
    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 >>
  17. Pascal
    Pascal avatar
    1 posts
    Member since:
    Jul 2013

    Posted 04 Sep 2015 Link to this post

    Hello, 

    Is this memoryleak also happen in RadScheduleView for WPF ?

  18. Kalin
    Admin
    Kalin avatar
    1209 posts

    Posted 07 Sep 2015 Link to this post

    Hello Pascal,

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top
DevCraft banner