MVC C# project with a Kentico 12 back-end (no drag-n-drop web parts just using it as back end CMS, with calls to Kentico APIs for data). Basically, we're having a caching issue that only occurs on one of our environments (PROD). I believe this is more of an IIS or environment issue than a Kentico thing. Let me give you some specifics: Kentico 12 MVC v12.0.34 (upgraded from K11) and as stated before we're not using any web parts/components. Kentico is just the back-end CMS, and we use Kentico APIs to pull data for each page and have rolled our own views and models.
We have 2 environments, STG and PROD, both running Win Server 2016 that have a slightly different OS build version
STG: v1607 OS build 14393.3115, IIS v10.0.14393.0
PROD: v1607 OS build 14393.2999, IIS v10.0.14393.0
Within Kentico when we update a category, an event is wired for the UPDATE and runs the following code:
CacheHelper.TouchKeys(new[] { "cms.category|all" });
This clears ALL category caching (CacheDependency within Kentico) and when the webpage is refreshed the GetAllCategories method that pulls, you guessed it, ALL categories is called again. If you try it another time, you'll get a cached version until there's a change within Categories (or the cache timing runs out, something like a month). Works exactly as you'd think on the STG box.
Just to see what's going on, I added some Kentico informational logging to check what is happening at different places around this Update event firing. From the EventArgs I can get the source of the event (which category triggered it), and I can see when it's using the cached info and when it retrieves it from the db. Awesome.
The issue that I'm running into is when I run on PROD using the exact same code base, along with the same logging, and trigger the same event, the cache does not get released. The event logging says it has, but when the webpage refreshes, the GetAllCategories is not brand new but the last cached value. The only way to get the new version is to recycle the app pool or shutdown/startup the application within IIS.
There is no Output Caching on the class/methods. Same code base across 2 different servers.
Is there some environment variable or IIS setting that could have been set differently on the PROD box?
Any thoughts what could be causing this? Other places to look on the web server? Thanks for your help!
I've had a caching issue similar to this and it turned out that it was down to the Web Farm configuration.
The problem is that when you have the CMS and MVC both hosted on the same server Kentico cannot tell them apart in Web Farms.
Make sure that your CMSApp and MVC projects each have web.config keys to set the CMSInstanceNameSuffix key. This will help differentiate them in Web Farms and allow web farm tasks to be correctly generated for your MVC app.
I'm having issues getting the Output Cache Dependencies webpart to work.
Here is my setup:
Master page has 20m output cache
All pages inherit this
Master page contains a navigation webpart repeater
The custom data source caching works for the navigation repeater. I also placed an Output Cache Dependencies webpart on the master page with the following settings:
Use Default Cache Dependencies: True
Cache Dependencies:
nodes|mysite|NavigationItem|all
I would expect that making changes to a document type of NavigationItem would clear the output cache on the master page as the webpart is on the master page and all other pages inherit this master page but it seems I need to wait for the 20 minutes output cache to expire.
I have tried this with and without partial caching (using the same dependency keys). I also tried having no output cache on the navigation pages.
Is there something I'm missing or not understanding here?
EDIT
it seems it works when I use the partial cache on the navigation webpart after all
Have you checked for the presence of the cache dependency key you've specified?
In Kentico 10, you can go to the "Debug" application, under "Cache Items", "Dummy Keys" and search for your document type.
https://www.screencast.com/t/vGEK8hkjdY
Edit a page, then search the dummy keys for "navigationitem" to see if anything shows up.
Most document types have a class prepended to them - I'm wondering if your cache dependency should read "nodes|mysite|cms.navigationitem|all" or something similar.
Best of luck!
Incase anybody comes across this issue...
The output cache dependency (settings -> system -> performance) didn't have device profile and browser set, that was the issue.
2 popular Wordpress plugins, Super Cache and Contact Form 7 - there are still some issues expected around _nonce AJAX calls.. How it is possible to make them work together smoothly? Definitely, there are some situations you want to keep ALL your posts (pages) super-cached, and not to be served dinamically without caching while preserving and providing contact form functionality.
When not checking the "Cache rebuild" in the settings, Super Cache will function:
standard pages will NOT enforce a new cache file to be generated (e.g. it REALLY serves an (if) existing supercache file whithout triggering a new cache file to be generated
pages with a wpcf7-form included WILL enforce/trigger the re-generation of supercache file while serving the initial on the request. I think that is the point when things go wrong.
Question: How to stop unwanted re-generation of pages with a wpcf7-form included? Based on wpcf7 plugin homepage Docs by the author, my expectation is that the wpcf7 form has evolved and been developing to meet this ajax-call requirements such _nonce calls. Any idea how to resolve this?
to be hard-coded (e.g. exclude _nonce call and/or URL parameter..) within wpcf7 form (this is against WP standards) or
settings in Super cache?
any other idea, solution or alternatives?
In this thread wpcf7 author says:
Contact Form 7 uses WP nonce as secret key. As nonce life is 24 hours by default, if cache clears less than 24 hours, the two plugins should work without problem, even if the page is cached.
Why it is sometime necessary to do Cache management to disable and Index management to re-index in magento.I am new in magento so if you know then reply this kindly.
In your development environment its advised to disable the cache because you tend to make the changes in the template / layout files often so to get it reflected on the frontend / website you are advised to disable the cache in your development environment. But don't do it in PRODUCTION.
And coming to Index Management, set it as "Save on Update" mode so that each time if you make some changes to your products, categories or attributes its getting re-indexed automatically and avoids the necessity to re-index it every time manually.
Specifically, "Block" data are the html blocks that the MVC generates to present to the frontend and even in the admin sometimes. Because of the caching and also session information, you need to log out of admin and back in for some changes to appear.
Depending on site volume, there might not be a penalty for turning off caching. If I'm doing a quick styling fix, I'll disable the block cache for a couple minutes.
I need to clear the IIS cache on my server. The exact reason is detailed below; but the reason doesn't matter. I'm 100% sure that this is the solution I need; as detailed below, I have used the process of elimination to determine that this is, indeed, the problem I'm facing, and the solution I need.
I have an MVC3 app that's themeable (skinnable architecture). Think of it as Wordpress; users can develop a theme, download it, and activate it on their site. The theme controls exactly the final HTML output. This is an over-simplification, since I provide an API with useful functions to be consumed by themes.
Anyway, users can change the theme of the site. The theme is currently stored in a static variable. When a view page is rendered, the name of the theme determines the location of the layout file (which contains references to the CSS files, etc.) and the view files. The theme is a setting that persists in the DB.
For example, if I have a theme called "Foo", then when requesting the /Admin page, I might use /Themes/Foo/Admin.cshtml. If I have another theme called "Bar" which does not have that file, then for /Admin it might request /Themes/Bar/Generic.cshtml as the layout.
The problem is that changing a theme means that every single page on the site is outdated. This means that any sites cached on IIS7 will show the old theme; this is incorrect. I need them to show the new theme.
Anyway, IIS7 uses caching by default. I need essentially a way to clear the cache when a user changes the theme. Currently, this is not happening, and users continue to see the old theme until the cache (somehow) expires itself.
I am not using output caching, or any other form of explicit caching; this is a "vanilla" ASP.NET MVC3 application from a caching perspective (i.e. I didn't add/configure any caching). IIS7 has its own default caching. I know this, because if I disable output caching in IIS7 for my Site, I will always see the correct theme after a change.
How can I flush the cache? Other SO questions point to using Cache.blah, and I tried using HttpContext.Current but that is null during tests (using VS test tool) -- because the ASP.NET pipeline is not used in full.
To explain, in an integration test, I basically:
Go to localhost/Test/
Log in (submit values into the forms)
Change the theme by browsing to the right page and clicking the right link
Request another page
See if the theme changed (based on the layout/css file name).
This is all done by code; I use a C# port of HtmlUnit, and along with deploying my app to /Test in IIS, I can essentially browse it like an end user.
Currently, this test passes around 50% of the time. The problem is that IIS is caching the results, and I can't cleanly reliably reset the cache on the server-side.
Again, I'm not talking about clearing the session or the user-side cache; IIS itself is the culprit guilty of caching my application. Nor do I want to completely disable the cache via the IIS settings, a) because I can't force people who install my application to do that, and b) because caching is good.
So how can I force flushing the cache on the server?
For example, I tried programatically touching web.config; this works, but recycles my application pool, and so, kills my static variables; every request means reloading all the static vars from the DB, which kills my performance.
As you requested I have amended this post:
You can use output cache, you say that the selected theme is stored in the database ( like settings for the site ) Well I would add another column with say a GUID and then use this as the varybycustom value.
Your global.asax file will be able to run code:
void Page_Init() {
///code here to get the GUIDforthissitestheme
var outputCacheSettings = new OutputCacheParameters() {
Duration = Int32.MaxValue, //think its maxvalue
VaryByCustom = GUIDforthissitestheme
};
InitOutputCache(outputCacheSettings);
}
At least here you will have output cache, but also every change of theme, changes the GUID so therefore changes the cache and then your page should be new.
I did something like this on a site that listed products, and when the products database was updated the key would be changed, however I can't find what site I implemented it and I work on a hell of a lot of sites.
hope this helps
Set up 'Cache Rule' in 'Output caching' feature with 'File Cache Monitoring' set to 'Using file change notification'. Then 'touch' the files theme change affects, from .net code you could do:
System.IO.File.SetLastWriteTimeUtc(fileName, DateTime.UtcNow);
The issues you are describing sound a lot like a client side caching issue. Have you checked this with a HTTP Proxy like Fiddler to verify if this is getting cached on the client?
If you are seeing HTTP 304's after a template change you may want to try configuring IIS (or your site template) to disable client side caching.
I dont think the approach mentioned for themes is correct.
If we are using STATIC variables , then it will affect all the users and all the pages.(Which is certainly not required.)
We can think of two approaches,
Use theme name in url and make it as a prat if RouteData. So the url "http://myHost/BLUE/.." will return in BLUE theme and "http://myHost/RED/.." will return in RED theme. If user will change theme then url will be updated.
The problem with above approach is next time user browse, it will load default theme.
So better approach will be save theme as a part of user preference. Once user logged in read the theme from DB and set the RouteData value.
Just touch web.config. That's the easiest and most reliable way. Flushing the application pool programmatically is overkill.
If you have a problem finding out where web.config is in a test environment (since System.Web.HttpRequest.Current is null, and similar for Server), you can always use an app.config file to point out the location.
Again, there's no other easy way to do it; even disabling output caching, as mentioned in the question, is hard to do through web.config alone.