On systems where the scheduler mode is set to REQUEST_MODE - there is a possibility that the code that is triggered on the httprequest handler - to attempt to start the scheduler - can be executed more that once.

http://www.dnnsoftware.com/forums/forumid/216/threadid/497534/scope/posts discusses the issue at some length - including debug logs that demonstrate it happening.

But in essence - the call to RunSchedule() is made every time a request is made for a page on a dnn site. When the application pool is starting up - it is currently possible for the SchedulingProvider.ReadyForPoll test to return true more than once. If there are multiple new page requests hitting the server during the application pool startup.

This is a common occurrence on low demand dnn sites that dont utilize any sort of keep alive tool - when those sites are visited by a crawler. For example.

Site is offline

• crawler targets the site - potentially firing off a number page requests at all but the same time.

• Asp.net sees first request and starts the process of bringing the dnn application into the application pool.

• while this is happening other requests start arriving.
  During this phase the DotNetNuke Http Application handler starts catching Application_BeginRequest events.

• One of the actions this triggers is the call to RunSchedule.

Inside RunSchedule - the systems tests to see if SchedulingProvider.ReadyForPoll is true - which basically it is taking to mean the scheduler is not currently running.

If this is the case is then starts the process of creating a new SchedulingProvider.Instance() thread - which ultimately brings the scheduler online.

BUT the problem is - there is potentially a considerable lag between when SchedulingProvider.ReadyForPoll is tested and found to be true - and when the system has got the scheduler thread running and SchedulingProvider.ReadyForPoll is eventually put into a start that allows it to return a value of false.

IF there are multiple httprequest arriving at the server during this phase - see the forum thread for example from debug log test - in the time between when the first request tests ReadyForPoll - other requests can also have tested ReadyForPoll - and all get to see the result of the test as TRUE.

At which stage - they each of those page requests all try to start triggering the process of starting up a schedulerprovider background worker thread.

On my test system - i was easily able to trigger 3 or 4 separate instances of the schedulerprovider on a regular basis - simply by manually starting 4 browser pages at the same time – on a system being hit by a search crawler - that often fire off 5-10 or more requests at once - it would not be unlikely for that to be the case .... AND ironically may be the cause of a number of different system event log errors and forced application pool restarts that clients have reported in the past that seem to always relate to sites being hit be web crawlers.

To fix the issue - I am suggesting that a lock() statement on a static local object should be added - this will prevent more than one instance of the schedulerprivider ever being created

If the file - DNN Platform\Library\Common\Initialize.cs

-------------------------------------------------------
private static readonly object _schedulerStarting = new object();
public static void RunSchedule(HttpRequest request)
{
if (!IsUpgradeOrInstallRequest(request))
{
try
{
lock (_schedulerStarting)
{
if (SchedulingProvider.SchedulerMode == SchedulerMode.REQUEST_METHOD && SchedulingProvider.ReadyForPoll)
{
Logger.Trace("Running Schedule " + (SchedulingProvider.SchedulerMode));
var scheduler = SchedulingProvider.Instance();
var requestScheduleThread = new Thread(scheduler.ExecuteTasks) { IsBackground = true };
requestScheduleThread.Start();
SchedulingProvider.ScheduleLastPolled = DateTime.Now;
}
}
}
catch (Exception exc)
{
Exceptions.LogException(exc);
}
}
}