none
MemoryCache get in Disposed state Magically

All replies

  • This might be happening if ASP.NET AppDomain is unloaded then handler of the AppDomainUnloaded in memory cache instance will call dispose.

    Since ASP.NET Cache is meant for web applications, I don't know is this bug in MemoryCache or some design that you should consider if using it in web application. Documentation does not give any instructions how to use MemoryCache in web applications so I have assumed you should not use it.

    Monday, September 03, 2012 12:44 PM
  • MasaSam, I thought could be the AppDomain Unload, but after some investigation I don´t think that is it:

    1-) MSDN says to use MemoryCache for ASP.NET: http://msdn.microsoft.com/en-us/library/ff477235(v=vs.100).aspx

    And says that ASP.NET 4 cache is built with ObjectCache:

    In ASP.NET 4, caching is implemented by using the ObjectCache class.

    2-) AppDomain unload would reset statics variable, creating new MemoryCache instances.

    3-) I attached a event to AppDomain Unload like the MemoryCache does(I saw the decompiled source) in my test it wasn´t called and memorycache get  disposed.


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4


    • Edited by Felipe Fujiy Tuesday, September 04, 2012 1:24 AM
    Tuesday, September 04, 2012 1:10 AM
  • A workaround (not a good one) is to change Pooling Interval to something like 30 hours(since default IIS recycle time is 27h).

    I realized that MemoryCache is getting disposed after 2 minutes, the default Pooling Interval.

    It´s working for 10 hours until now. Before it have worked for 20minutes at best case.


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4

    Tuesday, September 04, 2012 1:21 AM
  • I have recently had this issue on a Webapp also. However I have been using MemoryCache just fine on old IIS6 configuration. When moving to IIS7 I noticed this problem. Therefore I played around a little bit and found this is further related to running in Integrated (managed pipeline mode) as opposed to Classic and another 'fix' is to change back to Classic mode.

    Not only does this issue cause your Cache to become disposed after the polling interval, I also noticed that this can adversely affect some Performance counters - such as .Net Data Provider for SqlServer which also seems to disappear for that webapp pool instance after the polling interval and the MemoryCache gets disposed.

    I looked for error or warnings in event viewer and turned on error tracing but no error or warning is thrown the object is just disposed after the polling interval.

    Perhaps there is something in my webapp life-cycle that is incompatible with Integrated managed pipeline and the MemoryCache implementation but I really have no idea what it could be.

    Other solution presented are to use httpruntime cache or httpcontext caches but I am really curious as to why this doesn't work going from Classic -> Integrated and in my case IIS6 to IIS7.

    Is there any reason not to run in Classic mode given this works?

    Thanks for any ideas and I hope the extra info is of use to someone.

    Wednesday, September 26, 2012 12:50 PM
  • I filed a bug on Connect with a reproducer and some more info on reproducing.

    Basically needs to be windows Auth webapp, app pool running as a specific user, Integrated pipeline mode and then your memorycache gets disposed after polling interval

    https://connect.microsoft.com/VisualStudio/feedback/details/764911/memorycache-gets-disposed-after-pollinginterval-when-used-in-webapp-in-integrated-pipeline-mode#details


    I wonder if the app pool user or the auth'd user does not have permissions to do memory management on cache or if there is some timeout on the app pool user in integrated mode?
    Tuesday, October 23, 2012 10:39 AM
  • So, here's some news. We looked into this and YES, this is a bug in .NET 4.

    The good news is that it was fixed in .NET 4.5, so if you can, update your installation to .NET 4.5 and you're solid.

    The other good news it that this fix has been back-ported to .NET 4 and will be available as a QFE (Quick Fix...a one off fix you'll apply) #578315. It was backported/fixed and it should be out ASAP. I'll try to get an exact date, but it's soon.

    The other other good news is that there's a workaround for this on .NET 4 before the QFE. The workaround is weird, but it could unblock you.

    using (ExecutionContext.SuppressFlow()) {
       // Create memory cache instance under disabled execution context flow             
       return new YourCacheThing.GeneralMemoryCache(…);
    }

    Hope this helps.

     


    Scott Hanselman

    Saturday, March 30, 2013 7:08 AM