views:

225

answers:

4

Hi all,

I am currently using Quartz Scheduler for asynchronous tasks such as sending an email when an exception occurs, sending an email from the web interface, or periodically analyzing traffic.

Should I use a message queue for sending an email? Is it any more efficient or correct to do it that way? The scheduler approach works just fine.

If I use a queue and the email failed to send, is it possible for the queue to retry sending the email at a later time? The queue approach looks simpler than the scheduler for tasks that need to happen immediately, but for scheduler tasks, the scheduler still, unless there is more to the queue than I am aware of.

I have not yet used JMS, so this is what I have read.

Walter

A: 

A queue would be a more natural choice for sending things like email. Quartz can be shoe-horned into it but it is not a natural fit when you things like retry. A scheduler is most suited to exactly what the name suggests -- tasks that are supposed to occur periodically.

Tom Cabanski
A: 

I agree, with Tom that such asynchronous communication is best done through queue. Which works like a publish-subscriber model following the observer pattern.

Shamik
A: 

They are really different and it depends on the purpose and frequency you want to send an email. The scheduler generates an event that is time based and then runs some code to send an email. A queue has no way of triggering an event, it needs to have a message put on it from somewhere and then a MessageListener send an email.

To answer your question a queue is a good instrument to send an email if

  1. The message needs to be put back on the queue if the operation fails, even though SMTP does not know if the email reached it's destination.
  2. Some trigger can put a message on the queue.

The scheduler can run some java code at a certain interval and therefore generates temporal events. If you want to send periodic emails then the scheduler is the way to go.

If you go with the scheduler then you should have the scheduler put a message on a queue. If not then you need to have some other trigger put a message on the queue.

Romain Hippeau
Romain - that sounds good. I accepted your comment because it is a little more descriptive. I think I will go with a queue then. If the email fails to be sent, my failure mode would be to try another type of notification.
@Walter White Email is not a guaranteed delivery system. If you must deliver this email then you have several options.1) Post it on your web site and let the person sign in and see any updates th their account. 2) Put an URL in your email to have them click if they received the mail, if not keep sending on a periodic basis. Still not guaranteed, you just know when the got it.3) Send a letter with the email (Let's say it is account information from a bank) The letter can be registered if needed.2)
Romain Hippeau
A: 

Could somebody give me a link to some example of sending emails with queue. Thank you.

http://docs.jboss.org/seam/2.2.1.CR1/reference/en-US/html/jms.html#d0e21731If you're using JBoss Seam, you can fire an event to be processed (a)synchronously. You can use JMS to back the event bus, use an external ESB, Quartz, etc. In my case, I have enough durability and fail over that I chose not to use Quartz here. I fire an event which is then processed in another thread and context. Seam automatically handles the queue here.