Applicazione ASP.Net MVC 3 in modo casuale al riciclo del pool di applicazioni

Question

Ho un server Windows 2008 R2 e un'applicazione Web ASP.Net 2.0 in esecuzione sul sito Web predefinito in IIS, utilizzando Classic .NET AppPool. Sotto ho un'app virtuale che esegue MVC 3 utilizzando l'appPool pipeline integrata di ASP.NET v4.0.

Ogni tanto l'app MVC virtuale si guasta dopo che i pool di applicazioni si sono riciclati automaticamente. La correzione consiste nel riciclare manualmente l'AppPool di ASP.NET 4.0. Ho solo bisogno di riciclare una volta e risolve sempre il problema.

Gli errori dell'applicazione che ricevo sembrano gli errori che si verificano quando gli assembly non si caricano correttamente. Sono costituiti da NullReferenceException e Object reference not set to an instance of an object per controller e modelli di visualizzazione.

Il problema è che non riesco a riprodurlo su richiesta per eseguire correttamente il debug del problema. Avevo pensato che l'ordine di riciclaggio delle applicazioni potrebbe essere un problema, quindi ho impostato il pool classico per il riavvio tutte le sere alle 1:00 e il pool integrato per il riavvio alle 1:15. Sfortunatamente questo non ha aiutato.

Questa risposta relativa a assemblies being loaded on demand è interessante, tuttavia non sono sicuro del motivo per cui l'errore si verifica solo raramente e apparentemente a caso.

Qualcuno ha un'idea di come sarei in grado di ricreare in modo coerente il problema e/o una soluzione potenziale? Grazie.

aggiornamento per includere traccia esempio di stack:

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

Dopo aver esaminato più stack, il colpevole sembrava sempre risiedere con Entity Framework.

This question sembrava molto simile a quello che stavamo trovando. Abbiamo una teoria simile: potrebbe esserci una condizione di competizione nell'ordine in cui ASP.Net carica gli assembly, con il risultato che Entity Framework a volte "si spezza". Abbiamo implementato la risposta as mentioned e ha funzionato fino ad ora. La parte frustrante è che non siamo mai stati in grado di riprodurre coerentemente il problema, quindi solo il tempo ci dirà se la correzione ha funzionato.