CODEWITHSUNDEEP
javaqueuejakarta-mail
TheBigB
TheBigB

Reputation: 400

To queue or not to queue with Java mailing

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:

The arguments I recognize against queuing:

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!

Upvotes: 3

Views: 4299

Answers (5)

Grigory
Grigory

Reputation: 465

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.

Upvotes: 5

user207421
user207421

Reputation: 311039

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.

Upvotes: 1

Deepak Agrawal
Deepak Agrawal

Reputation: 1301

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.

Upvotes: 0

Ezequiel
Ezequiel

Reputation: 3592

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

Upvotes: 1

Bill Shannon
Bill Shannon

Reputation: 29971

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.

Upvotes: 3

Related Questions