アプリケーションプールのリサイクル時にASP.Net MVC 3アプリケーションがランダムに失敗する

Question

Windows 2008 R2サーバーとClassic .NET AppPoolを使用してIISの既定のWebサイトで実行されているASP.Net 2.0 Webアプリケーションがあります。その下に、ASP.NET v4.0統合パイプラインAppPoolを使用してMVC 3を実行する仮想アプリケーションがあります。

MVC仮想アプリケーションは、アプリケーションプールが自動的にリサイクルされるたびに頻繁に失敗します。修正プログラムは、手動でASP.NET 4.0 AppPoolをリサイクルすることです。私は一度だけリサイクルする必要があり、常に問題を解決します。

私が受け取るアプリケーションエラーは、アセンブリが正しく読み込まれていないときに発生するエラーのようです。コントローラとビューモデルの場合は、NullReferenceExceptionとObject reference not set to an instance of an objectです。

問題は、問題を適切にデバッグするために必要に応じて再現できないことです。私はアプリケーションプールのリサイクルの順序が問題であると思っていたので、毎晩1amでClassicプールを再起動し、午前1時15分に再起動するIntegratedプールを設定しました。残念ながら、これは助けにはなりません。

この回答はassemblies being loaded on demandに関して面白いですが、私はエラーが稀にしか発生せず、一見無作為に発生する理由は不明です。

どのようにして問題を一貫して再現できるか、潜在的な解決策を誰もが知っていますか？ありがとうございました。例えば、スタックトレース含まれるように

更新：複数のスタックトレースを確認した後

Exception information: 
    Exception type: NullReferenceException 
    Exception message: Object reference not set to an instance of an object. 
    at Bookstore.Controllers.BooksController.<>c__DisplayClass78.<Details>b__76(Grade g) 
    at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate) 
    at Bookstore.Controllers.BooksController.Details(String booktitle) 
    at lambda_method(Closure , ControllerBase , Object[]) 
    at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters) 
    at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters) 
    at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<>c__DisplayClass39.<BeginInvokeActionMethodWithFilters>b__33() 
    at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass4f.<InvokeActionMethodFilterAsynchronously>b__49() 
    at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<BeginInvokeActionMethodWithFilters>b__36(IAsyncResult asyncResult) 
    at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<>c__DisplayClass2a.<BeginInvokeAction>b__20() 
    at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult) 
    at System.Web.Mvc.Controller.<>c__DisplayClass1d.<BeginExecuteCore>b__18(IAsyncResult asyncResult) 
    at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) 
    at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult) 
    at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) 
    at System.Web.Mvc.MvcHandler.<>c__DisplayClass6.<>c__DisplayClassb.<BeginProcessRequest>b__4(IAsyncResult asyncResult) 
    at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) 
    at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() 
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) 

Answer 1

を、犯人は常にEntity Frameworkのに常駐するように見えました。

This questionは、私たちが見つけたものと非常によく似ています。同様の理論があります。ASP.Netがアセンブリをロードする順序で競合状態が発生し、Entity Frameworkが時には「破損」することがあります。私たちは答えas mentionedを実装しました。不満を募るのは、問題を一貫して再現することができなかったことです。そのため、問題が解決したかどうかは時間だけでわかります。