Using JMS or ThreadPool to send emails

Question

I would like to know:

I have a script. If a user adds a product to the system (I’m developing), there is a listener who sends a notification to the client base of the user, notifying about a new product added by the user.

I read this thread and (since I had never used JMS and ThreadPool before), I was wondering if I should use JMS or ThreadPooling.

I use Tomcat 5.5 and above, and JBoss 5 and above (depending on the last resort) to deploy my web application.

If I use JMS, can I use Apache ActiveMQ or JBoss Messaging ? Are both compatible for both platforms (Tomcat and JBoss)?

Thanks in advance.

Answer 1

For communication between applications, JMS is a very good solution, especially for events and notifications. JMS allows you to send and receive such notifications using the so-called asynchronous messaging, according to which the sender and receiver do not know each other and should not be available at the same time.

ActiveMQ is a very widely used message broker that provides client APIs for Java, C / C ++, C #, Perl, PHP, Python, Ruby and others. This allows you to use JMS with applications written in Java and other languages.

I have implemented JMS messaging many times for a large number of business situations to handle events and notifications. The vast majority of these times, I recommended and / or used Spring JMS no matter which message broker is used. Spring JMS is incredibly easy to use, extremely robust and highly scalable. Spring JMS eliminates the complexity of creating your own message producers and message consumers, which can save you a tremendous amount of time.

To find out how easy it is to send messages using Spring JMS, see a blog post I recently wrote called Using Spring JmsTemplate to Send JMS Messages . I am also working on a blog post about receiving posts using Spring JMS.

If you have further questions, let me know.

Bruce

Answer 2

I had the same requirement and we used JMS. Then the main problem was how to deal with errors, because SMTP is really not transactional:

• is it ok if some kind of email is lost?
• is it normal if multiple emails are sent twice?

We decided that it is better to send a message twice, and here is more or less the design that we had:

• We relied on a container-managed transaction, and if for some reason the email could not be sent, we decided to cancel the JMS transaction; the message will be resent by JMS, and a new attempt has been made to send the message.

• If the JMS message delivery transaction failed after sending the email message (for example, due to a problem with the JMS), the transaction will be automatically rolled back and the message will be resent later. In this case, the message was sent twice because the STMP protocol is not transactional.

• Even if an email message can be sent (in terms of code), the SMTP server may still have problems later. In this case, the JMSs were delivered and used, so we were unable to find out which email was processed and how to send them manually.

But we have already used JMS. I would not have presented JMS just for this, given that the main argument is that JMS is transactional, but SMTP is not anyway.

I would go for something easier — perhaps with ThreadPool — and save the state in a database to find out which email should be sent or sent. If there is any problem, you can look at the database and make special decisions.

Answer 3

I know that this answer is very late for this discussion, but I hope that it will continue to be useful for people looking for information on integrating ActiveMQ and Tomcat.

I had a lot of people who asked me for help in the issues that they integrated with ActiveMQ and Tomcat, so I decided to write some articles about this. Not only is this topic covered in ActiveMQ in action (see Chapter 8), but I also published a series of articles on it called ActiveMQ and Tomcat: Perfect Partners . I hope people find this useful.

Answer 4

I would go for a permanent JMS (I used only WLS JMS and Websphere MQ, so I can not compare AQ against JBoss, depending on which one best guarantees delivery). In addition, I would seriously consider making the email engine a completely separate application, depending on how much traffic you expect.