Gestione di eventi e chiamate API Web in arrivo contemporaneamente

Da ciò che stai descrivendo, mi sembra che potresti avere un problema con il modello di threading per il tuo ciclo di elaborazione degli eventi (ad esempio il gestore di messaggi RabbitMQ) e come funziona la concorrenza di ASP.NET.

Ci sono due modi per affrontare questo problema: in-process e out-of-process.

In-processo: Usa un thread in background dedicato per il tuo ciclo degli eventi, uno che è isolato dai thread che stanno elaborando le richieste http.
Fatelo in Application_Start. Ciò ti darà la concorrenza che stai cercando: gestire le richieste HTTP in arrivo e amp; ascoltare i messaggi allo stesso tempo.

Purtroppo, lo stai facendo in un framework di applicazione che non è stato progettato per questo stile di elaborazione del lavoro. Phil Haack esplora perché un thread in background di lunga esecuzione e un ciclo di elaborazione degli eventi è esattamente quello, in ASP.NET è problematico Quindi, a seconda del contesto, potresti essere felice di ignorare la superficie dei problemi in quel post. Il principale da considerare è che i pool di applicazioni, per impostazione predefinita, vengono abbattuti dopo 20 minuti. Questo è fondamentalmente in-compatibile con il modello di processo always-on che richiede un loop di eventi.

Fuori processo:

Interrompere la gestione dei messaggi RabbitMQ nell'applicazione ed esporre invece ciascun tipo di elaborazione dei messaggi come una chiamata API RESTy triggerata HTTP. Introdurre un processo bridge RabbitMQ-to-HTTP (un servizio Windows o anche un'applicazione console) che ascolterà i messaggi Rabbit e attiverà il metodo RESTy appropriato.

Lo svantaggio di questo approccio è la maggiore complessità della distribuzione e devi considerare la distribuzione come parte degli scenari di errore. Il bello è che la tua applicazione principale funziona solo via HTTP e il tuo processore di messaggi RabbitMQ è molto semplice, senza problemi di threading. Tutto ciò dovrebbe facilitare lo sviluppo e i test, nonostante l'aumento del livello di distribuzione.

Variation : anziché andare su HTTP-centric per la tua applicazione principale, vai su Rabbit-centric e crea un HTTP - > RabbitMQ bridge invece e converti le tue chiamate REST esistenti in equivalenti attivati dal messaggio. Non lo consiglio, perché sei sempre dipendente da un broker di messaggi molto particolare per lavorare, mentre HTTP è una tecnologia di integrazione onnipresente.