Smart Search index lock

Is there any auto-scaling configured? Which could cause multiple instances access one, shared folder while other instance has the files locked?

Hi Juraj, the web farms are in Manual mode now so I assume there is no auto-scaling. Would disabling web farm synchronization for smart search indexes be a solution here? Other than that I don't think there is anything custom configured for web farms

For example we turned off synchronization for media files since they are pulled in from a shared Azure blob storage so there was no need for synchronization there.

Well, I meant auto-scaling on Azure. If you are using blob storage for media files, isn't it possible that the Lucene index files are also mapped to a shared storage? If yes, the turning off the sync for search index files would make sense.

In a standard Kentico web farm setup, Automatic mode is preferred so Kentico can dynamically manage the instances. Manual mode can lead to sync tasks getting "stuck" if the server names or IP addresses change in the background.

disabling web farm synchronization for search indexes is not a solution. If you disable sync but continue to use a shared folder, the locks will still happen because both apps are still fighting over the same physical file.

Check the Azure Portal (under Configuration > Path Mappings) or the web.config to see if CMS_Search_CustomIndexPath is pointing to a shared drive. Smart search indexes would ideally stay on the file system, not in shared storage.

Media files are "read-heavy" and static; search indexes are "write-heavy" database-like files. You cannot treat them the same way in a cloud environment.

Thank you for the answers!

We haven't explicitly mapped the Index files to any storage folders like we did for Media Files. Since then I've switched to an automatic web farm setup to see if it would resolve the issue but it seems to be persisting.

As far as Azure goes, we have 2 instances set up for production that are running, might this be the issue for the CMS? I often see a mismatch in app state within the CMS when making some changes, for example I add a new field to a page type and if I switch between other fields the new field disappears and reappears for some time until it sticks even though it's all being served from one database. Could this be due to the multi-instances set up in Azure? It all seems to me like a misconfiguration in Azure somewhere where the app is inconsistently being served

Could you please clarify on your setup? How many instances and apps are there. By default there is an admin app and a front end app. Do you use auto-scaling or multiple instances for any of these? If yes, then keep in mind that when the app is scaled in Azure Web apps, it is still using one and the same file system - so a configuration for a shared file system is needed.

Hi Juraj, the setup is a standard kentico setup, 1 App service for the Admin app and 1 App service for the front end app. Both apps use a fixed number of 2 instances instead of auto-scaling. I think we're missing a shared file system setup for the search like we have for media files. I will set this up and report back if this resolved the issue finally, thank you

The same applies even if the instances are not auto-scaling. Still, multiple app instances are using one shared file system. I would recommend also mapping the media files and search index files into a separate file system such as blob storage - and either have one blob for admin apps and other one for front end app or, all instances can share one blob storage.