Impedire a IIS di uccidere un'attività prima che termini

Question

Sto costruendo una libreria di registrazione che memorizza tutto su una tabella di Azure. Scrivendo a quel tavolo prende ovviamente un sacco di tempo (non più di 1 secondo, ma è ancora troppo da rendere l'utente di attesa), quindi il metodo Log restituisce un'istanza LogResult, ecco la classe

public class LogResult 
{ 
    public string Id { get; set; } 
    public Task LoggingTask { get; set; } 

    public LogResult(string id, Task task) 
    { 
     Id = id; 
     LoggingTask = task; 
    } 
} 

Ed ecco come il metodo Log finisce

return new LogResult(id, Task.Factory.StartNew(() => 
    DoLogInAzure(account, id, exception, request)) 
); 

per dare al chiamante la possibilità di aspettare che sia completato (se si tratta di una console app, per esempio). Il problema che sto affrontando è che IIS non dovrebbe attendere prima di riportare l'utente la risposta ... e se non aspettare che, IIS non sempre eseguire l'operazione. L'idea è di mostrare all'utente un messaggio "... Se ci contatti, assicurati di menzionare il numero del tuo problema, XXX" e non farlo aspettare fino a quando non è stata scritta la voce del registro.

Esiste un modo per imporre a IIS di attendere fino al termine dell'attività, anche dopo aver restituito la risposta? Sto pensando che potrebbe essere necessario codificare un servizio di Windows che accetta la richiesta in modo asincrono, ma sembra molto lavoro solo per aggiungere una voce di log ... specialmente se posso forzare IIS ad aspettarlo.

Grazie per qualsiasi idea!

Answer 1

Grazie a Damian Schenkelman e al post sul blog di Phil Haack, ho capito il problema e la soluzione. Il problema è che IIS riutilizza i thread quando deve gestire nuove richieste. E poiché non sa che il mio compito sta facendo del lavoro, riutilizza quel thread (che ha senso). Quindi, devo solo notificare a IIS che sto usando quel thread e che non può essere riutilizzato (quindi, deve riutilizzare un altro thread, crearne uno nuovo o farlo attendere). Ho finito per utilizzare il mio TaskFactory che gestisce la creazione dell'attività e registra automaticamente un notificatore in IIS. Per completezza, per aiutare qualche altro folk con lo stesso problema come me, e per leggere un altro suggerimento, ecco quello che ho fatto

public class IISNotifier : IRegisteredObject 
{ 
    public void Stop(bool immediate) 
    { 
     // do nothing, I only run tasks if I know that they won't 
     // take more than a few seconds. 
    } 

    public void Started() 
    { 
     HostingEnvironment.RegisterObject(this); 
    } 

    public void Finished() 
    { 
     HostingEnvironment.UnregisterObject(this); 
    } 
} 

E poi

public class IISTaskFactory 
{ 
    public static Task StartNew(Action act) 
    { 
     IISNotifier notif = new IISNotifier(); 
     notif.Started(); 
     return Task.Factory.StartNew(() => { 
      act.Invoke(); 
      notif.Finished(); 
     }); 
    } 
} 

Ora, quando voglio iniziare un compito registro io faccio solo

return new LogResult(id, IISTaskFactory.StartNew(() => 
    DoLogInAzure(account, id, exception, request)) 
); 

Si può vedere (e scaricare il codice) a https://github.com/gmc-dev/IISTask

Answer 2

This post da Phil Hack parla di esecuzione le operazioni in background in un'applicazione ASP.NET.

Answer 3

Le informazioni non sono sufficienti ma sospetto che potrebbe essere correlato a GC e riferimenti se funziona quando si attende l'operazione. Per il tuo scopo, un modo migliore è utilizzare ETW (EventProvider) e impostare ActivityId per ogni richiesta. Basta configurare una sessione ETW in grado di reindirizzare tutti i messaggi su un file. Puoi mostrare ActivityId (un Guid) all'utente finale.

Answer 4

Ci scusiamo per non averlo aggiunto come commento, non ho abbastanza rep.

https://msdn.microsoft.com/en-us/library/system.web.hosting.iregisteredobject(v=vs.110).aspx

Le applicazioni possono avere una sola istanza di un tipo registrato.

Questo sembra indicare che risposta accettato di Gervasio Marchand è in qualche modo corretto, in quanto ogni chiamata al suo metodo di supporto statica crea una nuova IISNotifier, che è un IRegisteredObject.