ASP.Net MVC 3 Anwendung zufällig nach Anwendung Pool-Recycling

Question

Ich habe einen Windows 2008 R2-Server und eine ASP.Net 2.0 Web App läuft auf der Standard-Website in IIS, mit Classic .NET AppPool. Darunter habe ich eine virtuelle App, die MVC 3 mit dem integrierten Pipeline-AppPool von ASP.NET v4.0 ausführt.

Gelegentlich schlägt die virtuelle MVC-App nach dem automatischen Recycling der Anwendungspools fehl. Die Lösung besteht darin, den ASP.NET 4.0-AppPool manuell zu recyceln. Ich muss nur einmal recyceln und es behebt immer das Problem.

Die Anwendungsfehler, die ich erhalte, scheinen wie die Fehler, die Sie erhalten, wenn Assemblys nicht ordnungsgemäß geladen werden. Sie bestehen aus NullReferenceException und Object reference not set to an instance of an object für Controller und View-Modelle.

Das Problem ist, dass ich dies bei Bedarf nicht reproduzieren kann, um das Problem ordnungsgemäß zu debuggen. Ich hatte gedacht, dass die Reihenfolge der Anwendungspools Recycling ein Problem sein könnte, so dass ich den Classic-Pool jeden Abend um 1 Uhr neu starten und den integrierten Pool um 01:15 Uhr neu starten. Leider hat das nicht geholfen.

Diese Antwort auf assemblies being loaded on demand ist interessant, aber ich bin mir nicht sicher, warum der Fehler nur selten auftritt, und scheinbar zufällig.

Hat jemand eine Vorstellung davon, wie ich das Problem und/oder eine mögliche Lösung ständig neu erstellen könnte? Vielen Dank.

aktualisiert Beispiel Stack-Trace enthalten:

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

Nach der Überprüfung mehr Stack-Traces, schien der Täter immer mit Entity Framework zu wohnen.

This question klang sehr ähnlich zu dem, was wir fanden. Wir haben eine ähnliche Theorie: Es könnte eine Wettlaufsituation in der Reihenfolge geben, in der ASP.Net Baugruppen lädt, was dazu führt, dass Entity Framework manchmal "bricht". Wir haben die Antwort as mentioned implementiert und es funktioniert so weit. Der frustrierende Teil ist, dass wir nie in der Lage waren, das Problem konsistent zu reproduzieren, so dass nur die Zeit zeigen wird, ob der Fix funktioniert.