Servizio WCF: il modo migliore per accettare richieste da un cliente e svolgere attività in background?

Question

Servizio WCF: il modo migliore per accettare richieste da un cliente e svolgere attività in background?

#1 da (2 voti)

2

Per un progetto al lavoro, sono stato incaricato di creare un servizio WCF che riceverà messaggi e-mail dal client e li accoderà su un database, mentre allo stesso tempo il servizio controllerà il DB ogni 30 minuti circa per verificare se ci sono nuovi messaggi e-mail in coda e li inviano automaticamente con le credenziali appropriate.

Per riuscirci, il mio capo mi ha detto di farlo con i thread: mentre il thread principale è incaricato di prendere richieste dai client, una thread in background sarà incaricata di controllare il DB finché il servizio sarà attivo, e inviare le e-mail in coda. Dopo aver chiesto su StackOverflow , tuttavia, mi è stato detto che per questo tipo di scenario due servizi è un'opzione migliore, un servizio WCF che accetta richieste e un diverso servizio di Windows che fa funzionare lo sfondo.

Quindi la mia domanda è: qual è l'opzione migliore per implementare questo tipo di scenario? E lo sta facendo con solo discussioni possibili, ma sconsiderate? Mi piacerebbe sentire più opinioni prima di verificare con il mio capo il modo migliore per farlo.

.net multithreading wcf

posta Ana Ameer 09.05.2014 - 23:48

fonte

1 risposta

Leggi altre domande sui tag .net multithreading wcf

Come si consegnano messaggi a (e si interroga da) siti con possibilmente cattiva connettività, con numerosi servizi WCF di sapone e Web API? Fare in modo che le applicazioni costruiscano il sistema

score 2 · Accepted Answer

Se si ospita il servizio WCF su IIS:

L'esecuzione di attività lunghe da un'applicazione Web che utilizza IIS è una cattiva idea:

IIS ricicla AppDomains a intervalli regolari; questo potrebbe non essere ciò che desideri se ti trovi nel bel mezzo di un'attività lunga.
IIS ricicla AppDomain quando vengono aggiornati file come web.config.
Può avere un impatto negativo sulle prestazioni.

Quindi sì, se hai bisogno di un'attività in background, usa invece un servizio di Windows.

Fonti:

Attività a lunga esecuzione di ASP.NET. L'eccezione del thread è stata interrotta

You can start the long-running process in its own application domain.

In the past, when I've needed this capability, I create a Windows Service for this purpose. [...]
Che cosa fa riciclare un pool di applicazioni in IIS?

[...] this can be recycled by a number of effects e.g. time - every 'n' hours, lack of requests, memory use etc. [...]
Posso utilizzare i thread per eseguire lavori di lunga durata su IIS?

[...] In addition to reducing resources available to IIS/ASP.NET to process requests, you also have issues with the thread being killed when the AppDomain is recycled, and then you have to deal with persistence of the task while it is in-flight, as well as starting the work back up when the AppDomain comes back up. [...]
Come devo eseguire un'attività di lunga durata in ASP.NET 4?

Preferentially, avoid having long tasks executing in such an environment.

Delegate long running tasks out to a stable system service [...]

Windows services are designed to be long running, and if something goes wrong you've generally got more to worry about than your individual service.

Se si esegue il servizio WCF come servizio di Windows:

Separare il servizio Windows che ospita l'applicazione WCF dal servizio Windows che esegue l'elaborazione in background può avere due vantaggi:

Se uno dei servizi si arresta in modo anomalo, il secondo non viene modificato. Questo è un vantaggio minore, poiché se uno dei servizi si blocca, potresti avere preoccupazioni più urgenti.
È possibile ospitare ciascun servizio su un server dedicato. Anche questo vantaggio è probabilmente minore, a meno che tu non stia elaborando molte informazioni.

Per quanto riguarda l'utilizzo di un singolo servizio e due thread, non vedo alcun problema di blocco come quando il servizio è ospitato su IIS.