https://discord.umbraco.com logo
Join Discord
Powered by
Azure - Web App - Examine fails An error occurred ...
# help-with-umbraco
s
V10 latest - a live site running as an Azure Web App with all the recommended appsettings https://docs.umbraco.com/umbraco-cms/v/10.latest-lts/fundamentals/setup/server-setup/azure-web-apps Seems to have Examine issues. There are lots of log entries for "An error occurred processing the index batch." - Unpublishing deleting nodes fails. As far as I'm aware it was working fine and then this happened overnight. It could be related to a deployment swap - currently just deploying from VS via a publish and swapping in the portal. How does everyone else do this - is there anything special? The dev section for Examine refuses to load so the only option System.IO.FileNotFoundException: Could not find file 'C:\home\site\wwwroot\umbraco\Data\TEMP\ExamineIndexes\ExternalIndex\_e2_1.del'. File name: 'C:\home\site\wwwroot\umbraco\Data\TEMP\ExamineIndexes\ExternalIndex\_e2_1.del'
I've checked and the file it's trying to open doesn't exist. So shouldn't it try to recover / rebuild in this situation?
Only fix was to stop site delete the /TEMP/ ExamineIndexes folder and restart. Not idea for a site in production.
k
Are you sure you have 
"LocalTempStorageLocation": "EnvironmentTemp"
? The location is under the wwwroot, but maybe that's how Azure sets the environment variable for web apps... and also 
"LuceneDirectoryFactory": "SyncedTempFileSystemDirectoryFactory"
?
s
Just to triple check:
That looks right to me?!
k
It does. When you deploy from VS, do you take the app offline? And do you delete additional files from the web app?
It sounds like some of the Lucene files were removed, but not all. The 
.del
looks like the file was renamed because it was intended to be deleted? Those files normally are extensionless, right?
For our production Azure deploys, we use "take app offline" and "delete additional files" but we also need to configure retriies and delays to avoid some Umbraco files being "in use" anyway, especially log files and media cache files. Not sure it's ever happened with Lucene files.
A stray log file being left after a deploy wouldn't harm anyone, but a stray Lucene file would.
Is this a load-balanced setup, i.e. a multi-Azure-web-app?
s
Not load balanced. I don't take the app offline - I deploy to a deployment slot and swap. I was really hoping things were going to be a bit smoother in deployments with .net core... . seems I'm in for a dissappointment! The app service restart does take a minute or so so that's downtime.
I need to setup proper deployment scripts - ideally from Git Hub. The code actually gets deployed to 7 servers (differnet regions) so this manual deployment via VS is unstainable anyhow.
h
>>bit smoother in deployments with .net core Unfortunately not, you have to take the app offline to update dlls now, something you didn't have to previously with IIS.
s
Isn't that the entire point of deployment slots?
Sorry - I'm no Azure expert, perhaps I just want to believe too much!
k
You can absolutely deploy to a slot and swap. But if the slot is running it's hogging those DLLs
m
We deploy to slots and on swap shut down the "staging" slot as it's not needed and uses resources
Also if your deploying to 7 servers as far as Examine and the notifications system I'd argue you are load balanced
k
Are those 7 servers self-contained? Own databases, file systems etc? Otherwise, you need to configure load-balancing or things like publishing will fail sometimes.
s
7 completely separate websites on separate domains, separate content and db (they target different regions but on the same codebase). So not load balanced. I think I need to go look up how a deployment slot works. My, perhaps, niave assumption was that it had it's own file system and was like a separate IIS instance. This is why I expected Examine to #JustWork as it would build fresh indexes when it spun up, start in it's own space and then the requests as they are served are just swapped over to this.
m
Thats my understanding, do you keep your staging slots running after you swap?
k
A slot is a completely isolated app. It's just like a separate app but with a "logical" connection to the other slots and the app itself. Its own file system, own wwwroot, own everything.
Your Examine problems are probably completely unrelated to your slotegy and swapping. I think stray Lucene files on your slot just failed to delete during slotploy, hence the 
.del
rename and the non-working Examine afterwards.
s
OK - based on that I'm going to keep an eye on it. Test Examine indexes after release, stop the deploy slots after swap and see if it goes down again. Thanks all for your insight so far.
2 Views
PreviousNext
Powered by