Cache only cleared on Azure deployment slot instance
We have Umbraco 8.6.8 hosted on Azure Web Service. It has one backoffice server and one frontend server. It is using deployment slot during deployment.
Deploying to the slot and swap the slot work fine.
But we found out that after publishing on the backoffice server, the page cache is not cleared on the frontend server, but it is cleared on the deployment slot instance. If we restart the frontend server, then everything is fine.
After the slots have swapped, the applications in both slots restart, the application in the deploy slot re-acquires the MainDom from the "new" production slot.
I have to create a "deployment slot setting" which set the vale of "Umbraco.Core.MainDom.Lock" to empty in the slot application, so that only in the production slot it has the value "SqlMainDomLock".
This seems to work now, but is there any disadvantage?
I can see that in V9, theMainDom is no longer an internal class and the GetMainDomId method accepts an IHostingEnvironment object. That will be nice for v8 as well. By doing that, I can inject a custom IHostingEnvironment object which generates unique id for the slot and the production application respectively.
In you last comment, you mentioned that the applications restart. Why do the applications restart after slot swap? For us that would defeat the purpose of slot swapping in the first place.
The whole objective here should be to warm up Umbraco so that its indexes and caches are created before performing the slot swap into live.
Is this restart triggered by yourselves or is this just what happens.
Would be very interested to learn more as we are considering slot deployment currently.
Have you configured your application to be load balanced? While you may not be load balancing in a pure fashion, if you are triggering a cache reset from a "master"/back-end without the correct configuration in place, then Umbraco does not get told to reset the cache on the other instance.
Essentially each deployed Umbraco instance needs to know whether it is the Master or a Replica instance.
The Master manages publishing and adds cache instructions to the umbracoCacheIntructions table whilst the Replicas check that table every 5 seconds to find out if they need to update their cache and index files.
We have a setting in web.config that is set on deploy (by Octopus), to Master for the Backoffice App Service, and to Replica for the frontend app service.
Cache only cleared on Azure deployment slot instance
We have Umbraco 8.6.8 hosted on Azure Web Service. It has one backoffice server and one frontend server. It is using deployment slot during deployment.
Deploying to the slot and swap the slot work fine.
But we found out that after publishing on the backoffice server, the page cache is not cleared on the frontend server, but it is cleared on the deployment slot instance. If we restart the frontend server, then everything is fine.
Has anyone experienced this before?
Hello, YuQing Zhang
It´s a large question so i need something before i can narrov it down to help.
The cache we talk about, is that some self implentetde? Or do you mean the Umbraco cache?
Hi Lucas,
It is related to the Umbraco cache.
After some investigation, it seems that the issue is related to this one even though it is about v9: https://github.com/umbraco/Umbraco-CMS/issues/11935.
After the slots have swapped, the applications in both slots restart, the application in the deploy slot re-acquires the MainDom from the "new" production slot.
I have to create a "deployment slot setting" which set the vale of "Umbraco.Core.MainDom.Lock" to empty in the slot application, so that only in the production slot it has the value "SqlMainDomLock".
This seems to work now, but is there any disadvantage?
I can see that in V9, the
MainDomis no longer an internal class and theGetMainDomIdmethod accepts an IHostingEnvironment object. That will be nice for v8 as well. By doing that, I can inject a custom IHostingEnvironment object which generates unique id for the slot and the production application respectively.Hi YuQing Zhang
In you last comment, you mentioned that the applications restart. Why do the applications restart after slot swap? For us that would defeat the purpose of slot swapping in the first place. The whole objective here should be to warm up Umbraco so that its indexes and caches are created before performing the slot swap into live. Is this restart triggered by yourselves or is this just what happens. Would be very interested to learn more as we are considering slot deployment currently.
Regards
Jules
Hi Jules,
That was triggered by us to clear the cache. Swapping slots will not trigger restart.
Regards, Yuqing
Hi again
So your setup is 2 AppServices? One for Umbraco backoffice access and one for Front end?
Jules
Hi YuQing Zhang,
Have you configured your application to be load balanced? While you may not be load balancing in a pure fashion, if you are triggering a cache reset from a "master"/back-end without the correct configuration in place, then Umbraco does not get told to reset the cache on the other instance.
The documentation for this is here
I was building up to this :D. You beat me to it!
Essentially each deployed Umbraco instance needs to know whether it is the Master or a Replica instance.
The Master manages publishing and adds cache instructions to the umbracoCacheIntructions table whilst the Replicas check that table every 5 seconds to find out if they need to update their cache and index files.
We have a setting in web.config that is set on deploy (by Octopus), to Master for the Backoffice App Service, and to Replica for the frontend app service.
This article was excellent for version 8 - https://skrift.io/issues/umbraco-devops-part-1-how-to-configure-umbraco-to-run-on-azure/
Jules
is working on a reply...