Application restarting when a folder under Media is removed


Repro steps:
  1. Create a new folder through Media Library.
  2. Upload some files (in my test simple jpgs were enough).
  3. Open at least one of the uploaded files in your browser (e.g. navigate to the Media Library folder, select the file, click on the link at Filename to the right).
  4. Delete the folder.
  5. Experience the application being restarted as also made apparent with below exceptions being thrown from the framework.
System.Threading.ThreadAbortException occurred
Message: A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
Additional information: Thread has aborted. (Exception from HRESULT: 0x80131530)
This only happens with local Media, so this is not an issue when e.g. using Azure Blob storage.

This could be caused by FileChangesNotifications (see: http://stackoverflow.com/a/20214706/220230) but a) there is no corresponding Event Log entry and b) after trying various ways to disable FCN it still happens. So it seems it's something else. Also see: http://stackoverflow.com/questions/2248825/asp-net-restarts-when-a-folder-is-created-renamed-or-deleted

Was the same issue: https://orchard.codeplex.com/workitem/19284

I have no idea how this can be solved but this is one very painful issue for sites using local Media storage.
Closed Feb 27 at 8:14 PM by BertrandLeRoy
Unfortunately, I don't think we can fix IIS, which is responsible for that, and there is no clear workaround.


jao28 wrote Jul 16, 2014 at 1:42 PM

Hi Piedone, is this unique to Orchard 1.8.1 or do you think this has been present for a while. I have a monitoring system for my websites and (randomly) get notifications that the site is slow to respond. It doesn't turn into anything and by the time I visit the site everything is normal. I suspect it is some of my clients working on the Media folders that have caused a ripple down effect across the sites (i.e. we are on local media). However, there is nothing in the logs about why it has restarted. Just curious if there is any more insight into when this problem might have started to see if there is anything to be learned there.

jao28 wrote Jul 16, 2014 at 1:51 PM

I am looking for a solution locally. Your steps are accurate. Even to the point that if you don't do number 3 (i.e. open at least one of the uploaded files) but just go on to 4 (i.e. delete the folder) then nothing negative happens. Just seems strange that having accessed the file requires the application restart to trigger. I had thought that Orchard wasn't even handling these static resources.

Piedone wrote Jul 16, 2014 at 2:22 PM

I think this is something out of the reach of Orchard, specifically because a direct static file access (that goes directly through IIS, bypassing anything Orchard does) is enough to trigger it.

I have seen this with Combinator for ever. That means starting with about Orchard 1.4. I suspect this issue was present from the very beginning, unless it was caused some .NET 4+ (but 4.5 prior) change.

jao28 wrote Jul 16, 2014 at 2:52 PM

jao28 wrote Jul 16, 2014 at 2:56 PM

Further discussion here: http://stackoverflow.com/questions/2248825/asp-net-restarts-when-a-folder-is-created-renamed-or-deleted One of the arguments is that it is good behavior as we should not have dynamic content inside the app's virtual directory but I believe Orchard does with it's Media folder - unless you use some other external media host (such as Blob storage)

If we could just exclude the "Media" folder from being monitored, I believe that would be a fair balance!

jao28 wrote Jul 16, 2014 at 3:37 PM

This MSDN blog seems to further confirm it: http://blogs.msdn.com/b/toddca/archive/2006/07/17/668412.aspx

I tried the "fix" listed above but it doesn't seem to fix anything. The official Microsoft answer right now seems to be "just don't delete folders". Or better yet of course would be to not host the media inside same directory (I can't make that change yet though)...

Piedone wrote Jul 16, 2014 at 4:16 PM

Yes, as I mention in the issue, this seems to be caused by FCN, but I can't confirm it.

jao28 wrote Jul 16, 2014 at 5:06 PM

It took me that long to catch up to you :) consider me your audit. My research agrees with your findings.

I personally believe that rather than try and "fix" the issue, the Media folder should be stored outside of www root. Of course, the real question is where? I am going to work on moving over to Blob storage - hope someone else finds a way to either resolve this at the Media folder level or to move the Media folder somewhere outside of www root.

Piedone wrote Jul 16, 2014 at 6:23 PM

I think the best would be to place the Media outside the www root (what seems like the only generally available solution). This would be possible on standard shared hosting too.

The only issue I can think about regarding this is that I don't know how it would be possible to create the Media folder with its Web.config, since it can't be deployed with the web app. Probably this could be done the first time Media is accessed, from some service.

CSADNT wrote Jul 16, 2014 at 6:35 PM

In a past system I was storing all images in slq server, keeping only a uniquely named physical version to serve web requests in a sole folder. Then when I was copying the db, I had just to restore all the images in the cache folder.
No need to manage real folders, only full virtual (double).
But it was in a WebForm app with a dedicated image handler.

Piedone wrote Aug 18, 2014 at 10:54 PM

BertrandLeRoy wrote Feb 27 at 8:12 PM

I don't think having the media folder outside of wwwroot will fix it: you will still have to tell IIS to serve those files, so it will be monitored, and you're back to square one.