To queue or not to queue with Java mailing

Question

The scenario is the sending of a password reset mail to the user from a web request (and possibly other mail related tasks in the future).

The arguments I bring to the table for queuing:

• I believe web requests should be handled as fast as possible

• Decoupling the send action from the request, more easily allows externalization of the mail system (if required in the future)

The arguments I recognize against queuing:

• The user does not get feedback if something goes wrong during the sending of the message

What are more arguments in this discussion? And to those in favor of queuing, how would you implement the queue? Scheduled action? Infinite dequeuing task (with interval, of course)?

Thanks!

Answer 1

I would suggest you to decouple actual sending of mail from your app business logic. Do this asynchronously: Use queue or at least different thread for sending such notifications.

1. Sending of email could be time consuming operation, even if you use your own internal mail server which is close to your app. SMTP conversation consists of several requests/responses.
2. Do not treat sending of a mail as a transactional action. When target SMTP server replies with 250 OK as a response for DATA command - it just takes responsibility for this mail nothing else. Delivery could fail in future if next server in the chain is not able to deliver mail (read about DSN, aka bounce).
3. Last but not least think about failure modes. What if your business critical functionality is slowed down / blocked by auxiliary one (email notification), not good I guess.

Answer 2

You definitely don't want to do the send synchronously since the mail server may be slow.

Send a JMS message and use an MDB to send the email.

Answer 3

In a Java EE 6+ scenario you can use @Asynchronous annotation in a EJB method. It returns a Future<V>. So you can continue with proccesing and ask later for task ending, while it is executed in another thread. So you can accept a lot of request fastly, you decouple the send action from request, and you can get feedback. http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html

Answer 4

You may think that requests should be serviced as fast as possible, but what about the user? What does he think?

The user needs his password reset. He doesn't care how long that takes. If he can't complete that request he can't do anything at all.

Don't queue.

Answer 5

I think u should go to queue. Because it help in fast performance and to check whether the password reset request is arrived from correct source.

So u can use Map for queue implementation. Because in map u can use email id as key and a unique request reference as value. And this map element should be deleted within a time period.

Also for fast email service u can create a simple thread class that send emails and start a new thread by passing some data arguments in it. and scheduling will automatically managed by web container for these threads.