This project is read-only.

solution causes performance issues



I actually wanted to report an issue. I'm using these activities specially look up user info and infopath activities but on running WFs, I get "potentially excessive number of requests" message in the logs and this is causing performance issues to us where some of the workflows specially if the infopath form that the workflow is running on includes attachment have error in the WF (transaction time out) and sometimes this happens with forms without attachments and this is solved for the forms just without attachment by restarting WFs , we have a case opened with Microsoft and they informed us that this solution is causing alot of performance issues that most probably is the cause of our problem so please if anyone has encountered this issue let me know and below is a section from the logs showing the error so kindly advise if you could check this issue .

Potentially excessive number of SPRequest objects (29) currently unreleased on thread 43.  Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. This object is holding on to a separate native heap. Allocation Id for this object: {7AF7501E-1E04-4332-AF94-31B5679F53E8} Stack trace of current allocation:
    at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite site, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)
     at Microsoft.SharePoint.SPWeb.InitializeSPRequest()
     at Microsoft.SharePoint.SPFile.CheckOut(SPCheckOutType checkOutType, String lastModifiedDate)
     at DP.Sharepoint.Workflow.IPAccessHelper.SaveForm()
     at DP.Sharepoint.Workflow.InfoPath.IPAccessService.Commit(Transaction transaction, ICollection items)     at System.Workflow.Runtime.WorkBatch.PendingWorkCollection.Commit(Transaction transaction)
     at System.Workflow.Runtime.WorkBatch.Commit(Transaction transaction)


jherschel wrote Dec 6, 2013 at 6:41 PM

We have the same issue...