Asynchronous Email Processing in a Java Web Application

Question

I would like to implement asynchronous email sending in my web application when users register for a new account. This is so that if there is a problem or delay in sending an e-mail message (for example, the mail server is turned off or the network connection to the mail server is slow), the user will not continue to wait for the sending to be completed.

My web application is built using Spring and Hibernate JPA implementations.

What would be the best and most reliable way to implement asynchronous email processing in this web application?

I am thinking about storing email in a database table, which is then regularly checked by Quartz ( http://www.opensymphony.com/quartz/ ) for the scheduled task for updates and when it finds new unsent emails, it tries to send them.

Is this a smart way to implement what I want?

Thanks.

Edit:

The most vocal answer is to leave sending mail as a synchronous call, but what caused my opinion that an asynchronous approach might be the best is that I am currently using GMail as my outgoing mail server (this is for testing at that time like), and I experience a delay of 25 seconds in response when my application tries to send an email when the mail sending function returns. What do you think?

Answer 1

I would advise you not to worry. Most Unix-style MTSs came up with and improved deferred gear decades ago, and you don't have to reinvent the wheel. You will do it poorly (compared to sendmail or postfix), and you will miss something. My best advice is to use Java Mail APIS javax.mail and let the MTA work with the asynchronous part.

Answer 2

You can implement the queue manually using MySQL or some other persistent mechanism, but you can also use JMS to queue. It is quite suitable for such situations.

In this case, I will be tempted if you separate the mail component from the main application and let the two communicate using JMS. The main application places the message in the JMS, and the mail application will subscribe to the queue and try to process the messages.

JMS can be simplified (e.g. MySQL) using configuration.

The advantage of splitting Webapp is that you abstract from the notification mechanism and can implement it in the future, for example. Google Wave or IRC or something else without touching the main application.

Someone suggested using postfix or sendmail and letting them handle the order. This is also a great solution, especially if you put a postfix or sendmail on localhost and let it route messages further. Try setting up this mail program to allow only mail routing from the local host to prevent the creation of an open mail client :)

EDIT clarified the use of JMS + comment on local mail daemon

Answer 3

This is pretty reasonable, this is what quartz was built for.

However, note that you do not need to plan through the database at all (unless server downtime is a real problem). You can simply schedule Quartz to work without accessing the database (the simplest examples of quartz show you how).

Otherwise, if you choose access to the database, you have the opportunity to completely send emails from another application (this is good if you need it).

Answer 4

Java EE 6 makes this so easy with the @Asynchronous annotation.