Geeks With Blogs
Fringe SharePoint Continued

I recently developed a WCF solution with SharePoint that once I deployed cause so many issues with memory leak that it service was shutting down. If you are having issues with a WCF service that hits the SharePoint object model and it is unexpectedly shutting down, most likely it is because memory leaks. I will not write about simple memory leaks since there are lots of great blogs which cover the topic really well.

 I have had issues with LINQ and SharePoint and I wrote several .Net method extensions to deal with traversal and complex queries on SPWebCollection and SPSiteCollection, to properly dispose of the objects. So when I saw that my code was producing so much memory leaks enough to shut down the service I was quite surprized. The following is quite a common error message in your logs:

"Potentially excessive number of SPRequest objects (12) currently unreleased on thread 6.  Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed.  Allocation Id for this object"

If you are a new developer to SharePoint check out the follwing site to help you out with some simple standards for your code that will clean up a lot of your errors. The site also points you to an DisposeCheck tool. It's a start but it's by no means an indepth, fail proof check. A lot of issues are really internal to SharePoint, quarky methods that instantiate SPWeb and SPSite objects that basically a developer was never meant to administer. The rule has always been, if you create an object you are responsible of disposing it. If you use an existing object you are not responsible of disposing it. For example the SPContext object give you the ability to access SPWEB and SPSIte objects. You never instantiated those objects therefore you not to dispose.

  I looked over my code and it looked like it did not have any memory leaks. I also used the dispose tool with no luck but still I had memory leaks. A chunck of Stack trace is as follows:

  at Microsoft.SharePoint.Utilities.SPUtility.StackTraceString(Int32 numLevelsToSkip)
   at Microsoft.SharePoint.SPWeb.EnsureSPRequest()
   at Microsoft.SharePoint.SPWeb.get_Request()
   at Microsoft.SharePoint.SPListCollection.Add(String strTitle, String strDescription, SPListTemplate template)
   at Lis.SharePoint.Service.SpAdministration.CreateProject(String rootUrl, String prjType, String name, String templateName, String projectId)

 

I googled around and found this thread where someone was having a similar problem. My code was doing something really simple, It was creating a new document library based on a template. the code looked as follows:

                                Guid listGuid = targetsite.Lists.Add(name, "", temp);
                                SPList newList = targetsite.Lists[listGuid];         

This code was the problem. After looking up the SPListCollection object and doing a bit of googling somoene in some MSDN post wrote that this was a SharePoint bug, and that the code could not be fixed. So I decided to see what could possibliy be happening with the code. I stumpled onto the SPWeb.Update() method. I noticed that first, I did not include that in my code. I didn't include it simply because I didn't think I had to, The document library I created was created in SharePoint. I didn't want to perform a problematic update. I noticed that at the end of the Update method there was a call to "this.Isvalidate()" The code looks as follows:

internal void Invalidate()
{
    this.ReleasePinnedResource();
    if (this.m_Request != null)
    {
        if (this.m_RequestOwnedByThisWeb)
        {
            SPRequestManager.Release(this.m_Request);
        }
        this.m_Request = null;
    }
    this.m_bInited = false;
    this.m_bPublicPropertiesInited = false;
    this.m_Url = null;
}

It seems as thought he SPWeb.Update does a little more than commit changes to SharePoint, At least it doesn't seem to care about a new Document LIbrary being created since my document lib was showing up in sharepoint. IT is this Update that seems to release the Request SPWeb that is created internally. This released any objects that were created in the SPListCollection and during the creation of document libraries. When I included the SPWeb.Update() all my errors went away.

It seems like such a careless thing but this might save you an entire day!!! like it would have me!

 

On to the next problem.

 

 

 

Posted on Wednesday, January 27, 2010 6:35 PM SharePoint | Back to top


Comments on this post: Endless Memory Leak Issues Continued

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © juanlarios | Powered by: GeeksWithBlogs.net