Update: I have dropped the cache system in favor of a database solution - pitty.
I have a backend MVC controller where i need data caching. I use MemoryCache.Default to store key/value pairs, nothing big. Nevermind policies and expire times, i'f got that. The thing that mystifys me is why my cache gets cleaned out after I'f accessed a key (retrived the value) the first time. If i don't access the cached item, eventually the item will expire and my remove handler is called - it's all good. But when i retrive the item the first time, my remove handler is called after a short while. The ChacheEntryRemovedReason is set to:
CacheSpecificEviction // A cache entry was evicted for as reason that is defined by a particular cache implementation.
I can't find any explanation to what this means.
The mystifying thing here is that when i inspect the cache object when debugging in the handler (and on succeeding controller calls), the cache enum is empty. If I "set" (add) a new CacheItem to the cache, I can yet again access the key once, and history repeats.
The behavior is like a one-off caching mechanism which i totally don't need.
Any help or comments would be much appreciated!
Some simplified code just for the fun of it:
private static ObjectCache cache = MemoryCache.Default;
internal void insertInCache(string key, int value) {
CacheItemPolicy policy= new CacheItemPolicy() {
AbsoluteExpiration = ObjectCache.InfiniteAbsoluteExpiration,
Priority = CacheItemPriority.NotRemovable,
SlidingExpiration = TimeSpan.FromMinutes(ITEM_EXPIRE_TIME),
RemovedCallback = new CacheEntryRemovedCallback(RemovedHandler)
};
cache.Set(key, value, policy);
}
static void RemovedHandler(CacheEntryRemovedArguments args) {
if(args.RemovedReason == CacheEntryRemovedReason.Expired) {
//do something - or i actually want it to disappear when expired
} else {
cache.Set(args.CacheItem, somepolicy);//reinsert to keep in cache
}
}
//Apparently this triggers some cache mong mode
internal void getSome(string key){
int thisIsWhatIWanted = (int)cache.GetCacheItem(key).Value;
}
This is just example code so please don't nag me about my skillz.
My own best guess is that it may have to do with the cache not being setup properly, MVC witchery or the fact I'm running my application on a debug IIS (visual studido)
Related
I’m having issues with a static member of my app class losing its value and I’m not quite sure I understand why. In my app constructor I check if the user is logged in and if not redirect to a login page where I set the static app class member.
I understand if the app is forced to close to free up resources, these values are not retained so a new app instance would start and go back to login screen. However, what I’m seeing is the static member losing its value during an application session. I can do a check to see if this is null on resume and redirect to login page but I don’t understand why this happens.
My understaning was that the only way you would lose values would be if the app was killed in the background but this problem would suggest it can happen when resuming too.
In a normal C# application static members will typically survive forever, but unfortunately your observations are entirely correct; in Xamarin Forms static members are not guaranteed to persist for the length of the application's life.
In Android's case if the underlying platform indicates a low memory state (or increased demands on memory from multiple running applications) then static members are considered collectable by the GC, which is often triggered when you pause the application (ie. switching to a different app). They will be reduced to their default value, eg. null, zero, etc.
I've wrestled with this curio for years, and the most performant work around is to implement a re-population pattern on those static members, eg.
internal List<MyCustomType> _AListOfStuff
internal List<MyCustomType> AListOfStuff
{
get
{
if (_AListOfStuff == null)
{
PopulateAListOfStuff(); //If this occurs then the static member has been garbage collected: reload it
}
return _AListOfStuff;
}
}
From what you've said, I appreciate that your particular usage of static members probably doesn't fit with this solution, however all I can offer is that you're not crazy; it is a documented quirk, and not considered a bug (don't even bother shaking that tree; I've been down that route with the devs and was told in no uncertain terms that the behaviour is here to stay, and is necessary to ensure overall device stability).
Static member will not lose. If we see the code then we can assist further. Another approach would be, try using singleton pattern, it will create new instance only if it's instance is null. sample below:
public sealed class SingletonSample
{
private static SingletonSample instance = null;
private static readonly object padlock = new object();
public static SingletonSample Instance
{
get
{
lock (padlock)
{
if (instance == null)
{
instance = new SingletonSample();
}
return instance;
}
}
}
public string FirstName { get; set; }
}
I am trying to analyze what problem i might be having with unsafe threading in my code.
In my mvc3 webapplication i try to the following:
// Caching code
public static class CacheExtensions
{
public static T GetOrStore<T>(this Cache cache, string key, Func<T> generator)
{
var result = cache[key];
if(result == null)
{
result = generator();
lock(sync) {
cache[key] = result;
}
}
return (T)result;
}
}
Using the caching like this:
// Using the cached stuff
public class SectionViewData
{
public IEnumerable<Product> Products {get;set;}
public IEnumerable<SomethingElse> SomethingElse {get;set;}
}
private void Testing()
{
var cachedSection = HttpContext.Current.Cache.GetOrStore("Some Key", 0 => GetSectionViewData());
// Threading problem?
foreach(var product in cachedSection.Products)
{
DosomestuffwithProduct...
}
}
private SectionViewData GetSectionViewData()
{
SectionViewData viewData = new SectionViewData();
viewData.Products = CreateProductList();
viewData.SomethingElse = CreateSomethingElse();
return viewData;
}
Could i run inte problem with the IEnumerable? I dont have much experience with threading problems. The cachedSection would not get touched if some other thread adds a new value to cache right? To me this would work!
Should i cache Products and SomethingElse indivually? Would that be better than caching the whole SectionViewData??
Threading is hard;
In your GetOrStore method, the get/generator sequence is entirely unsynchronized, so any nymber of threads can get null from the cache and run the generator function at the same time. This may - or may not - be a problem.
Your lock statement only locks the setter of cache[string], which is already thread safe and doesn't need to be "extra locked".
The variation of double-checked locking in the cache is suspect, I'd try to get rid of it. Since the thread that never enters the lock() section can get result without a memory barrier, result may not be entirely constructed by the time the thread gets it.
Enumerating the cached IEnumrators is safe as long as nothing modifies them at the same time. If GetSectionViewData() returns an object with immutable (as in non changing) collections, you're safe.
Your code is missing parts like how would Products be populated? Only in GetSectionViewData?
If so, then I don't see a major problem with your code.
There is however a chance that two threads generate the same data(CachedSection) for the same key, it shouldn't create a threading problem except that you are doing the work twice, so if this was an expensive operation I would change the code so it only generates it once per key. If it is not expensive, it works fine as is.
IEnumerable for Products is not touched (assuming you create it separately per thread, but the enumerator on the cache is modified for each insert operation, hence it is not thread safe. So if you are using this I would be careful about that.
I have a pretty standard MVC3 application. I'm trying to store some data that's application-wide (not user wide) in a the cache (in this case, a Theme object/name). When debugging (on the development server that integrates with Visual Studio), if I call SwitchTheme, I see the new theme right away. On IIS7, whatever theme was cached, stays cached; it doesn't update to the new theme.
Edit: Some code:
public static Theme CurrentTheme { get {
Theme currentTheme = HttpContext.Current.Cache[CURRENT_THEME] as Theme;
if (currentTheme == null)
{
string themeName = DEFAULT_THEME;
try
{
WebsiteSetting ws = WebsiteSetting.First(w => w.Key == WebsiteSetting.CURRENT_THEME);
if (ws != null && !string.IsNullOrEmpty(ws.Value))
{
themeName = ws.Value;
}
}
catch (Exception e)
{
// DB not inited, or we're installing, or something broke.
// Don't panic, just use the default.
}
// Sets HttpContext.Current.Cache[CURRENT_THEME] = new themeName)
Theme.SwitchTo(themeName);
currentTheme = HttpContext.Current.Cache[CURRENT_THEME] as Theme;
}
return currentTheme;
} }
public static void SwitchTo(string name)
{
HttpContext.Current.Cache.Insert(CURRENT_THEME, new Theme(name), null, System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(30));
// Persist change to the DB.
// But don't do this if we didn't install the application yet.
try
{
WebsiteSetting themeSetting = WebsiteSetting.First(w => w.Key == WebsiteSetting.CURRENT_THEME);
if (themeSetting != null)
{
themeSetting.Value = name;
themeSetting.Save();
}
// No "else"; if it's not there, we're installing, or Health Check will take care of it.
}
catch (Exception e)
{
// DB not inited or install not complete. No worries, mate.
}
}
I'm not sure where the problem is. I am calling the same method and updating the cache; but IIS7 just shows me the old version.
I can disable output caching in IIS, but that's not what I want to do. That seems like a hacky work-around at best.
Without a code sample it's difficult to know what your problem is. In an attempt to provide some assistance, here is how I frequently set the cache in my applications:
public static void SetCache(string key, object value) {
if (value != null) {
HttpRuntime.Cache.Insert(key, value, null, System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(30));
}
}
The HTTP cache is reset only if you do so manually or the app domain (or app pool) resets for whatever reason. Are you sure that's not happening in this case? And generally speaking, any global static variables would also be maintained in memory under the same circumstances.
There are many reasons why an app pool might be reset at any given point, such as a change to a web.config file, etc. I suggest checking that's not happening in your case.
By the way, output caching is a different thing, although it is maintained in memory largely the same way.
Given that this only happens on IIS7 when Output Caching is not disabled, this seems very likely to be an IIS7 bug. Seriously.
Whether it is or not, is irrelevant to the solution. What you need to do is find some manual process of invalidating the cache, such as touching the web.config file.
But beware: doing this will wipe out the cache (as you expect), but also all static variables (as a side-effect). Whether this is another bug or not, I don't know; but in my case, this was sufficient to solve the problem.
I am attempting to use a file as a trigger to refresh my cached items. When the file is changed, I need to fire an event (every time the file changes). I'm currently using the HostFileChangeMonitor class. Here's where a cached item gets set, using a policy to link it to a file:
private static void SetPolicy(CacheNames cacheName, CacheItem item)
{
string strCacheName = cacheName.ToString();
CacheItemPolicy policy;
if (_policies.TryGetValue(strCacheName, out policy))
{
_cacheObject.Set(item, policy);
return;
}
policy = new CacheItemPolicy();
List<string> filePaths = new List<string> {
string.Format(#"{0}\{1}.txt",Config.AppSettings.CachePath,cacheName.ToString())
};
var changeMonitor = new HostFileChangeMonitor(filePaths);
_cacheObject.Set(item, policy);
changeMonitor.NotifyOnChanged(new OnChangedCallback(RefreshCache));
policy.ChangeMonitors.Add(changeMonitor);
}
The NotifyOnChanged fires only once, however. Because of that, I am currently removing and then re-adding the item to the cache in the RefreshCache method called by the NotifyOnChanged:
private static void RefreshCache(object state)
{
//remove from cache
WcfCache.ClearCache("Refreshed");
//resubscribe to NotifyOnChanged event
WcfCache.SetCache("Refreshed", true, CacheNames.CacheFileName);
//grab all cache data and refresh each in parallel
}
Is there a better way to do this? Is there an event I can tap into that will ALWAYS fire (instead of just the first time like this NotifyOnChanged)? This seems pretty fragile. If the HostFileChangeMonitor doesn't get added properly one time, the entire app's cache will never refresh.
Have you tried the FileSystemWatcher and handling its Change event?Here's MSDN's documentation on the subject for more detailed info.
I've just discovered this class and from what I get, the NotifyOnChanged is not meant to be fired every time a watched file is updated (even though the name lets you think otherwise).
Rather the file is constantly being watched and cached and you simply need to get it from the cache whenever you need it.
I have a combined authorization and menustructure system on our backend.
For performance reasons EntLib caching is used in the frontend client (MVC rel 1.0 website, IIS 5.1 local, IIS 6.0 server, no cluster).
Sometimes 'Cache.Contains' will return true, but the contents of the cache is NULL. I know for certain that I filled it correctly, so what can be the problem here?
EDIT: when I set the cache to 1 minute and add the cacheKey 'A_Key', I will see the key coming back when inspecting the CurrentCacheState. When I view CurrentCacheState after 2 minutes, the key is still there. When I execute 'contains', true is returned. When I execute 'contains' again, the cacheKey is gone!
Synchronization problem??
Regards,
Michel
Excerpt:
if (IntranetCaching.Cache.Contains(cacheKey))
{
menuItems = (List<BoMenuItem>)IntranetCaching.Cache[cacheKey];
}
else
{
using (AuthorizationServiceProxyHelper authorizationServiceProxyHelper = new AuthorizationServiceProxyHelper())
{
menuItems = authorizationServiceProxyHelper.Proxy.SelectMenuByUserAndApplication(APPNAME, userName, AuthorizationType.ENUM_LOGIN);
IntranetCaching.Add(cacheKey, menuItems);
}
}
And the cachehelper:
public static class IntranetCaching
{
public static ICacheManager Cache { get; private set; }
static IntranetCaching()
{
Cache = CacheFactory.GetCacheManager();
}
public static void Add(string key, object value)
{
Cache.Add(
key
, value
, CacheItemPriority.Normal
, null
, new Microsoft.Practices.EnterpriseLibrary.Caching.Expirations.AbsoluteTime(TimeSpan.FromMinutes(10)));
}
}
Thanks Michael for following up your own issue, I have been stuck with this all day identifying that if I try and retrieve an item from Cache this is due to expire (+ 0 up to 25 seconds) I will get a NULL value. Codeplex have posted a workaround (of sorts)as it is in their FAQ:
a. How do I avoid getting a null value from the CacheManager when the item is being refreshed? - Intermittently, you may encounter this situation. To work around this, create your own implementation of an ICacheItemExpiration. In the HasExpired()method, implement a logic that will check whether the item has already expired and will update the item's value if it has expired. This method should always return false for the item to not be tagged as expired. As a result of returning false in the HasExpired() method, the item will not be refreshed and will contain the updated value as implemented in the method.
REF: link
I got the following response from Avanade (creators of Entlib):
Most likely, the BackgroundScheduler
hasn't performed its sweeping yet. If
you're going to examine the source
code, the Contains method only checks
if the specific key is present in the
inmemory cache hashtable while on the
GetData method, the code first checks
if the item has expired, if it has,
the item is removed from the cache.
Sarah Urmeneta Global Technology &
Solutions Avanade, Inc.
entlib.support#avanade.com
That solution is working for me.
Still the question remains why you can use 'Contains' when its outcome cannot be used in a sensible way.
Regards,
M.