Elaborazione di e-mail asincrona nell'applicazione Web Java

Question

Vorrei implementare l'invio di e-mail asincrone nella mia applicazione Web quando gli utenti si registrano per un nuovo account. Questo è così che se c'è un problema o un ritardo nell'invio del messaggio e-mail (ad esempio il server di posta è inattivo o la connessione di rete al server di posta è lenta) l'utente non sarà tenuto in attesa del completamento dell'invio.

La mia app Web è costruita utilizzando l'implementazione Spring e Hibernate di JPA.

Quale sarebbe il modo migliore e più affidabile per me per implementare l'elaborazione e-mail asincrona in questa applicazione Web?

Sto pensando di mantenere le informazioni di posta elettronica in una tabella di database che viene regolarmente sottoposta a polling da un lavoro programmato Quartz (http://www.opensymphony.com/quartz/) per gli aggiornamenti e quando trova nuove e-mail non inviate, tenta di inviarle.

È un modo ragionevole di implementare ciò che voglio?

Grazie.

Edit:

Il più votato risposta è quello di lasciare l'invio di posta come una chiamata sincrona, ma che cosa è innescato il mio pensiero che un approccio asincrono potrebbe essere migliore è che sto attualmente utilizzando GMail come la mia posta in uscita server (questo è per il testing durante lo sviluppo) e sto riscontrando un ritardo di 25 secondi nella risposta da quando la mia app tenta di inviare l'e-mail al momento in cui la chiamata alla funzione di invio della posta ritorna. Cosa ne pensi?

Answer 1

Suggerirei di non disturbare. La maggior parte degli MTA in stile Unix ha inventato e perfezionato l'invio differito decenni fa e non si dovrebbe reinventare la ruota. Lo farai male (rispetto a sendmail o postfix), e ti mancherà qualcosa. Il mio miglior consiglio è di usare javax.mail Java Mail APIS e lasciare che il MTA gestisca la parte asincrona.

Answer 2

È possibile implementare l'accodamento a mano, utilizzando MySQL o qualche altro meccanismo permanente, ma è anche possibile utilizzare JMS per l'accodamento. È praticamente perfetto per questo tipo di situazioni.

In tal caso, sarei tentato di dividere il componente di posta dall'app principale e di comunicare con JMS. L'app principale inserisce un messaggio nel JMS e l'applicazione mailer si iscrive alla coda e tenta di elaborare i messaggi.

JMS può essere reso persistente (ad esempio MySQL) abbastanza facilmente mediante la configurazione.

Il vantaggio di suddividere la webapp è che si estrae il meccanismo di notifica e che in futuro potrebbe essere implementato ad es. Google Wave o IRC o qualsiasi altra cosa senza dover toccare l'app principale.

Qualcun altro ha suggerito di utilizzare un postfix o sendmail e lasciare che gestiscano l'accodamento. Questa è anche un'ottima soluzione, specialmente se si mette il postfix o sendmail su localhost e si lascia che instradi ulteriormente i messaggi. Non provare a configurare il programma mailer in modo tale che solo la posta da localhost è permesso di essere indirizzati, per evitare la creazione di un programma di posta aperta :)

EDIT chiarito l'utilizzo di JMS + commento sul demone di posta locale

Answer 3

E ' è abbastanza ragionevole, questo è il genere di cose per cui Quartz è stato costruito.

Tuttavia, si noti che non è necessario pianificare il database (a meno che il tempo di fermo del server sia un problema reale). Puoi semplicemente programmare un lavoro al quarzo senza accesso al database (gli esempi Quartz più semplici mostrano come).

Altrimenti, se si sceglie l'accesso al database si ha la possibilità di inviare le e-mail da un'altra applicazione completamente (una cosa carina se ne avete bisogno).

Answer 4

Java EE 6 rende così semplice l'annotazione @Asynchronous.