The issue I am facing is, when deployed to their Azure App Services, any new doc type changes are not picked up by the Master instances. We have to restart the App Service via the Azure Portal to see these changes. Once the Master instance has the latest doc type changes, a restart of the Replica instance is required to display the new content.
This is far from ideal and is quite frustrating as we have regular releases of our code, not to mention the disruption for end-users.
I have tried the Diplo ‘God Mode’ restart and clearing all caches via the back-office, which does not work. Only a hard restart of the App Service via the Azure Portal seems to resolve this issue.
The application is using uSync with the ‘ImportAtStartup’ set to ‘true’ for the administration instance, and so should pick up any doc type changes automatically.
Azure App Service restart required after deployment
Hi everyone,
I have an issue with an Umbraco 8 (v8.14.1) application deployed as two instances; Master (administration for back-office CMS changes) and Replica (public-facing for content delivery) having followed this setup - https://our.umbraco.com/Documentation/Fundamentals/Setup/Server-Setup/Load-Balancing/azure-web-apps-v8
The issue I am facing is, when deployed to their Azure App Services, any new doc type changes are not picked up by the Master instances. We have to restart the App Service via the Azure Portal to see these changes. Once the Master instance has the latest doc type changes, a restart of the Replica instance is required to display the new content.
This is far from ideal and is quite frustrating as we have regular releases of our code, not to mention the disruption for end-users.
I have tried the Diplo ‘God Mode’ restart and clearing all caches via the back-office, which does not work. Only a hard restart of the App Service via the Azure Portal seems to resolve this issue.
The application is using uSync with the ‘ImportAtStartup’ set to ‘true’ for the administration instance, and so should pick up any doc type changes automatically.
Any help would be very much appreciated.
Thanks,
+1, getting this as well. But in my case it is only sometimes and it is the caching not being updated.
I believe there is a race condition occurring on the SQLDOMLOCK when the swap occurs in our situation that blocks the public site from updating cache.
is working on a reply...