4

I've a group of asp.net 4.0 Websites runing in Azure Websites

  • Compute mode: Standard
  • Location: North Europe
  • Capacity autoscale: Off
  • Instance size: Large
  • Instance Count: 1

The response time is very slow, the trafic is normal, but my log show many AppDomain shutdowns (more than 3 in one minute). My websites load data in cache during de Application_Start to give a rapid response to all subsequents requests but if the Appdomains restarts every time is impossible to give acceptable response times.

The ShutdownReason values are many:

  • ConfigurationChange
  • HostingEnvironment
  • CodeDirChangeOrDirectoryRename
  • BinDirChangeOrDirectoryRename
  • BrowsersDirChangeOrDirectoryRename

This have no sense because I've not changed any file in these folders.

I've tested one of these sites in a free mode running very fast and without any unexpected AppDomain restart.

Thanks.

Update:

I've included this code in the Application_Start, no file changes have been detected and the AppDomain is restarting again, and again...

var monitorPath = HostingEnvironment.MapPath("~/");
Application.Add("watcher", new FileSystemWatcher(monitorPath));
fsw = (FileSystemWatcher) Application["watcher"];
fsw.EnableRaisingEvents = true;
fsw.IncludeSubdirectories = true;
fsw.Changed += fsw_Changed;
fsw.Created += fsw_Created;
fsw.Deleted += fsw_Deleted;
fsw.Renamed += fsw_Renamed;

Update 07/15/2013:

using the code from the ScottGu article http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx

I have logged this:

_shutDownMessage=Directory rename change notification for 'C:\DWASFiles\Sites\my-sitename\VirtualDirectory0\site\wwwroot'.
File Change Notification Error in wwwroot
HostingEnvironment initiated shutdown
Change Notification for critical directories.
File Change Notification Error in App_GlobalResources
Change Notification for critical directories.
File Change Notification Error in bin
Change Notification for critical directories.
File Change Notification Error in App_Browsers
Change Notification for critical directories.
File Change Notification Error in App_Code
Change Notification for critical directories.
File Change Notification Error in App_WebReferences
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
File Change Notification Error in C:\DWASFiles\Sites\my-sitename\VirtualDirectory0\site\wwwroot
CONFIG change
File Change Notification Error in 
HostingEnvironment caused shutdown
File Change Notification Error in 
Change Notification for critical directories.
File Change Notification Error in App_LocalResources
Change Notification for critical directories.
File Change Notification Error in App_LocalResources
CONFIG change

_shutDownStack=   at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownWithoutDemand()
   at System.Web.HttpRuntime.ShutdownAppDomain(String stackTrace)
   at System.Web.HttpRuntime.OnCriticalDirectoryChange(Object sender, FileChangeEvent e)
   at System.Web.FileChangesMonitor.OnSubdirChange(Object sender, FileChangeEvent e)
   at System.Web.DirectoryMonitor.FireNotifications()
   at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback)
   at System.Web.Util.WorkItem.OnQueueUserWorkItemCompletion(Object state)
   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Update 07/19/2013:

The metric Data-In is very high and has no relation with the requests metric, but when I configure the setting fcnMode=”Disabled” the data-In immediately down to normal values accord with the traffic.

  • Looks like you perform writes into root folder of your application of subfolders thereof. I guess your best bet is to obtain the list of files in root folder together with modification times and look carefully at them so that you find what triggers the restart. I once faced this issue myself and fixed it by eliminating the writes. – sharptooth Jul 12 '13 at 13:55
  • Did you check the /LogFiles folder using FTP or Kudu-VFS? This is where you would see any exception being thrown by your site. It's possible you are throwing an unhandled exception after returning the content which causes your site's worker process to terminate. Us the details in your publish profile to connect via FTP or log in to https://.scm.azurewbsites.net/vfs to use Kudu VFS. YOu can download your entire log directory with Kudu ZIP like this: https://.scm.azurewebsites.net/zip/LogFiles – MattD Jul 12 '13 at 17:53
  • The website is not writing any byte to the disk and the eventlog.xml only have a little group of exceptions. :-( – Alejandro Melis Fernández Jul 12 '13 at 19:26
  • There isn't any unhandled exception in the logs. – Alejandro Melis Fernández Jul 14 '13 at 14:55

1 Answers1

3

Using the new setting fcnMode in asp.net 4.5 (seems to work in 4.0) the AppDomain stops restarting

  <httpRuntime fcnMode="Disabled" />

But, the question now is why the FileChangesMonitor in azure Websites (at least in the websites in my subscription) give this _shutDownMessage:

File Change Notification Error in wwwroot
HostingEnvironment initiated shutdown
Change Notification for critical directories.
File Change Notification Error in App_GlobalResources
Change Notification for critical directories.
File Change Notification Error in bin
Change Notification for critical directories.
File Change Notification Error in App_Browsers
...

Update:

The cause was a bug in SMB that was affecting only the location North Europe.