locked
Memory leak when using Workflow 4.0 SqlWorkflowInstanceStore and PersistableIdleAction.Unload RRS feed

Answers

  • In the original link the owner pasted, the question was answered. I pasted it here for reference.

    Answer

    <input type="hidden" value="2740882" /> 0

    Seems like an interesting bug? I don't have the profiler you mention so a couple questions.

    • Is your investigation driven by some significant memory usage problems?

    • How sure are you that the unload action is really completed at the time of profiling (vs about to happen asynchronously, etc)?

    • It seems like the asynchronous chain is OK but the TdsParserStateObject would probably be the real object being leaked. I notice that class has a Dispose() method but doesn't implement IDisposable. So another idea is that Dispose() is used to manually 'reset' or 'recycle' the object at some distinct point in time - but that point in time turns out to be 'not yet (unload time) but later', e.g. lazy recycling. Does your profiler let you see whether the number of TdsParserStateObjects over time is increasing, to indicate a real leak there? As opposed to 'just a finite number of objects so not a real leak' leak.

    answered Apr 29 at 21:26
    After testing the scenario again (I loaded and idled 5000 workflows) it seems that over time (a few minutes after the workflows have idled) the workflow objects in memory are released. You may be correct in your assumption that the objects are recycled lazily. I am interested to find out what triggers this event. – Rohland Apr 30 at 7:41
    It may be a feature of the SqlClient class, you could try asking on the forum social.msdn.microsoft.com/Forums/en-US/… – Tim Lovell-Smith Apr 30 at 18:14
    Thursday, May 27, 2010 7:06 AM

All replies

  • Hi,

    Do you have a repro memory leak scenario? i.e. An application occupies unreasonable memory. I could not repro using the below. I do not see increasing memory usage over the time.

     

     

    while (true)

    {

    instance =

     

    new WorkflowApplication(root);

    instance.InstanceStore = store; <- this is a SQL instance store

    instance.PersistableIdle = OnIdlePersistence; <- set Unload persist action

    instance.Unloaded = Unloaded; <-set unloadEvent

    instance.Load(id);

    instance.ResumeBookmark(

     

    "read1", 1); <- Multiple resume bookmark

    unloadEvent.WaitOne();

     

     

    Thread.Sleep(1);

    }

    Tuesday, May 4, 2010 9:47 PM
  • In the original link the owner pasted, the question was answered. I pasted it here for reference.

    Answer

    <input type="hidden" value="2740882" /> 0

    Seems like an interesting bug? I don't have the profiler you mention so a couple questions.

    • Is your investigation driven by some significant memory usage problems?

    • How sure are you that the unload action is really completed at the time of profiling (vs about to happen asynchronously, etc)?

    • It seems like the asynchronous chain is OK but the TdsParserStateObject would probably be the real object being leaked. I notice that class has a Dispose() method but doesn't implement IDisposable. So another idea is that Dispose() is used to manually 'reset' or 'recycle' the object at some distinct point in time - but that point in time turns out to be 'not yet (unload time) but later', e.g. lazy recycling. Does your profiler let you see whether the number of TdsParserStateObjects over time is increasing, to indicate a real leak there? As opposed to 'just a finite number of objects so not a real leak' leak.

    answered Apr 29 at 21:26
    After testing the scenario again (I loaded and idled 5000 workflows) it seems that over time (a few minutes after the workflows have idled) the workflow objects in memory are released. You may be correct in your assumption that the objects are recycled lazily. I am interested to find out what triggers this event. – Rohland Apr 30 at 7:41
    It may be a feature of the SqlClient class, you could try asking on the forum social.msdn.microsoft.com/Forums/en-US/… – Tim Lovell-Smith Apr 30 at 18:14
    Thursday, May 27, 2010 7:06 AM
  • I have the same problem as Rohland has. When workflow unloads it does not release the memory.

    I have another problem.When I create the instance of SqlWorkflowInstanceStore an entry is added into LockOwnersTable table and it is not deleted as a result I have around 10000 entries in that table and their time is being updated by workflow engine more frequently as putting stress on sql server.

    Friday, June 3, 2011 7:55 PM
  • Hi all,

    Just want to bring back this issue for attention. I am having the memory leak problem in my WF system. Same behavior as described above and the following links:

    http://www.youtube.com/watch?v=xD0mRWJazis

     

    Can someone from Microsoft to conclude their findings on this issue? Is it true that there is no workaround or fix for this issue?

     

    Thank you.

     

     

    Thursday, August 4, 2011 3:03 AM
  • Hi all,

    Just want to bring back this issue for attention. I am having the memory leak problem in my WF system. Same behavior as described above and the following links:

    http://www.youtube.com/watch?v=xD0mRWJazis

     

    Can someone from Microsoft to conclude their findings on this issue? Is it true that there is no workaround or fix for this issue?

     

    Thank you.

     

     

    Hi greenpacketeer,

    I notice that in your video, when you reproduce this issue you are running in Debug mode, and I believe that this is probably a known issue where having the Visual Studio Workflow Debugger attached is keeping the workflow locked in memory in the debuggee process. Please try running your application in Ctrl+F5 mode where I think you will observe that there is no memory leak behavior.
    Tim

    Thursday, August 4, 2011 2:54 PM