Geeks With Blogs
Fringe SharePoint Continued

I had an interesting scenario where a bunch of memory leaks were showing up. I googled around and found a bunch of issues. I'm sure if you are reading this, you have either just started the search or have been to every blog post about memory leaks.

 This might be a bit repetative but if you are in the first group that just started maybe this is a nice way to point you in the right direction. You are probably experiencing errors that start like this:

 

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

 

or

"An SPRequest object was not disposed before the end of this thread.  To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it.  This object will now be disposed."

 

This is because you or SharePoint has instantiated these objects that have been left in memory and are causing memory leaks. There are 2 type sof memory leaks.

 

1) Carelessness or just was not aware that such object were meant to be disposed - SPWeb and SPSite objects are the main objects used to give developers a starting point into SharePoint development. These objects should be disposed properly. Google around for the appropriate way to dispose. There are many many links.

 

2) SharePoint instantiated objects - These objects are created indirectly by sharepoint. This is a microsoft error or bug. The rule of thumb is always , "create the object, dispose the object". If you did not create the object, there should be no resposability to dispose.

   examples of this are the Web part manager object, travesing or enumerating through SPListCollection. They both instantiate SPweb or SPSite objects that now need to be disposed by a developer that did not instantiate those objects.

   These are hardter to track and pin point because they are deep inside sharepoint code.

 

At the end of the day, it is possible to write Memory leak free code. But it is also possible for SharePoint to produce memory leaks that have absolutely nothing to do with your code. Stefan Gobner, who is involved with the Microsoft team wrote about handiling memory leak issues that are part of SharePoint code. The short of it is, if you are getting erros like this.

Potentially excessive number of SPRequest objects (10) currently unreleased on thread 14.  Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed.  Allocation Id for this object: {195665B9-954E-4595-971E-615251D6D88D} Stack trace of current allocation:    at Microsoft.SharePoint.SPRequestManager.Add(SPRequest request, Boolean shareable)     at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)     at Microsoft.SharePoint.SPWeb.InitializeSPRequest()     at Microsoft.SharePoint.SPWeb.EnsureSPRequest()     at Microsoft.SharePoint.SPWeb.get_Request()     at Microsoft.SharePoint.SPWeb.InitWebPublic()     at Microsoft.SharePoint.SPWeb.get_CurrentUser()     at Microsoft.SharePoint.Publishing.CacheManager.EffectivePermissionsCacheForCurrentUser(SPWeb contextWeb)     at Microsoft.SharePoint.Publishing.AclCache.GetEffectivePermissions(Guid scopeId, SPWeb contextWeb)     at Microsoft.SharePoint.Publishing.AclCache.UserHasRights(Guid scopeId, SPBasePermissions requiredPermissions, SPWeb contextWeb)     at Microsoft.SharePoint.Publishing.CachedObject.UserHasRights(SPBasePermissions permMask, SPWeb contextWeb)     at Microsoft.SharePoint.Publishing.CachedListItem.UserHasRights(SPWeb web)     at Microsoft.SharePoint.Publishing.CachedArea.CreateResultSetFromSuperUser(StringCollection superUserItemIDs, Dictionary`2 superUserCachedObjects, SPWeb contextWeb, SPQuery query)     at Microsoft.SharePoint.Publishing.CachedArea.GetChildForListByQuery(String listName, SPQuery query, SPWeb contextWeb)     at Microsoft.SharePoint.Publishing.Internal.WebControls.SiteManagerUtils.GetSmtReports()     at Microsoft.SharePoint.Publishing.WebControls.EditingMenuActions.ReportsNode.EnsureChildNodes()     at Microsoft.SharePoint.Publishing.WebControls.EditingMenuActions.ReportsNode.IsCurrentlyEnabled(AuthoringStates currentState)     at Microsoft.SharePoint.Publishing.WebControls.ConsoleDataSource.trimActionTreeForContext(ConsoleNode treeNode)     at Microsoft.SharePoint.Publishing.WebControls.ConsoleDataSource.trimActionTreeForContext(ConsoleNode treeNode)     at Microsoft.SharePoint.Publishing.WebControls.ConsoleDataSource.PopulateDataSource()     at Microsoft.SharePoint.Publishing.WebControls.XmlConsoleDataSource.PopulateDataSource()     at Microsoft.SharePoint.Publishing.WebControls.ConsoleDataSource.GetHierarchicalView(String viewPath)     at Microsoft.SharePoint.Publishing.WebControls.PublishingSiteActionsMenuCustomizer.OnPreRender(EventArgs e)     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at System.Web.UI.Page.ProcessRequest()     at System.Web.UI.Page.ProcessRequest(HttpContext context)     at ASP.DEFAULTLAYOUT_ASPX__296385485.ProcessRequest(HttpContext context)     at Microsoft.SharePoint.Publishing.TemplateRedirectionPage.ProcessRequest(HttpContext context)     at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)     at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)     at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)     at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)     at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)     at System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType) 

 

 

Notice the Red bolded text? THis seems to be a publishing issue. After trying severl things, a supoort call revealed what Stefan wrote in his blog. THis has to do with SharePoint navigation. Which is handled by the publshing feature. My code has nothing to do with it. Increasing the threshold that is described in the blog post does not seem like a solution to me but more of a cover up and hack fix. That's just my opinion.

All I know is memory leaks are huge issue now with SharePoint 2007. if you are new to this issue an starting your search, I hope you got a good start to understand what you are getting into now. Good luck.

 

Posted on Wednesday, February 24, 2010 1:48 PM SharePoint | Back to top


Comments on this post: Possible to write Memory leak free code, but SharePoint might still have memory leaks

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


Copyright © juanlarios | Powered by: GeeksWithBlogs.net