I'll just chime in here a bit as this is a very specific issue with Azure, or any other "dynamic" cloud environment. There are really two things that come together, with the infrastructure of using Azure in a multi-instance situation for App Services, which can cause issues.

1.) App Services uses an SMB Network Share for File System

Behind the scenes, your "Home directory" for your application is actually a mounted Azure Blob Storage account. This is fantastic, as you don't have to worry about DFS Replication or otherwise as it relates to the file system when you go to scale-out. However, this can manifest itself as a bit of an ugly situation for DNN in a couple places.

* Log4Net Logs - These are written to the /Portals/_default/logs directory, which being shared can have issues & writelocks. Often times this goes un-noticed, but can be addressed by changing the logging directory to the Azure suggested log directory. You can also, more than likely, adjust to include machine name, but I haven't done that yet.

* Lucene Lock Files - They have the same issue, but there is a second issue that makes this a bigger deal
* Third-party Solutions - You also want to look at any third-party items that you are using that write to the local filesystem as this infrastructure can cause issues if they, for example, use a "file-based" caching provider behind the scenes.

2. DNN Scheduler Not Smart Enough for Dynamic Environments

The second issue, or really the root cause, as you pointed out is the limitation of the DNN Scheduler to prevent execution on multiple servers. Currently, the DNN Platform has an ability to either execute a scheduled job on ALL servers, or a specific set of individually named servers. In the Azure App Service Environment, this doesn't work as your server name can change multiple times a day. There are a few workarounds.

1.) You can run a regular SQL Script that queries the listing of known servers, and picks one to assign the task. It isn't elegant, but works.
2.) You can do similar to what you mentioned with an out-of-band fork.

Going Forward

I have a plan, that I hope to be able to implement for 10.x that will introduce a few new features.

* A "Run On Single Server" option for jobs, to only execute 1 time per time-period
* A "Cleanup Servers" job that will keep the server's table pruned from outdated servers

If anyone wants to help work on those features, it would be appreciated.

Hello Mitchel.

Yes! The log4net issue is something we've seen but it's not as bad as the lucene lock files. I didn't think of changing the server dynamically. That may be an option but it needs to be coupled with a purge of inactive servers.

We went with the solution of extending the search task class because we had already implemented a way of limiting the number simultaneous of executions for a custom scheduled task and it was more convenient.

Thanks for your input. Hopefully this will help anyone facing the same issues.

Posted By Mitchel Sellers on 27 Jun 2019 10:14 AM
* A "Cleanup Servers" job that will keep the server's table pruned from outdated servers

Ah yes, Evoq has this! :)

 

Posted By Olly Hodgson on 27 Jun 2019 01:46 PM

Posted By Mitchel Sellers on 27 Jun 2019 10:14 AM
* A "Cleanup Servers" job that will keep the server's table pruned from outdated servers

Ah yes, Evoq has this! :)

 

Yup!  And initially it was committed to be contributed to the platform, but that decision changed.  As such, we are going to have to build our own.

 

 

Hi
This error occurs when the search scheduler wants to restart according to the timing set in the section for the default timestamp. Indexing is indexed in files.
My problem with this solution was solved
From the Admin> Schedules> Search: Site Crawler section, edit the "Time lapse:" section to 12 hours. And set the "Retry Repeat:" section to 6 hours. This causes the rescheduling to not interfere with the previous timing and you will not receive the corresponding error. And the problem of indexing searches regularly.
https://dnnplus.ir/Forum/...b3%d8%ae%d9%87-9-4-1

Might help to turn down the logging to only keep 5 or 10 records in the event log?