Using JMS or ThreadPool to send email messages

问题:

I will like to know:

I have a scenario. If a user adds a product to the system (I'm developing), there's a listener that sends a notification to the user's client base notifying of a new product added by the user.

I've read this thread and (seeing I've never used JMS nor ThreadPool before) I was wondering whether I should use JMS or ThreadPooling.

I am using Tomcat 5.5 and higher and JBoss 5 and higher (depending on company last resort) to deploy my web application.

If I use JMS, do I use Apache ActiveMQ or JBoss Messaging? Are they both compatible to run on both platforms (Tomcat and JBoss)?

Thanks in advance.

回答1:

For communicating between applications, JMS is a very good solution, especially for events and notifications. JMS allows for such notifications to be sent and received using what is known as asynchronous messaging whereby the sender and receiver have no knowledge of one another and no requirement to 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 more. This allows the use of JMS with applications written in Java and other languages.

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

To see how easy it is to send messages using Spring JMS, check out a blog post I wrote recently titled Using the Spring JmsTemplate to Send JMS Messages. I'm also working on a blog post about receiving messages using Spring JMS.

If you have any further questions, let me know.

Bruce

回答2:

I had a similar requirement once, and we used JMS. Then main problem was how to deal with errors because SMTP is indeed not transactional:

1. is it ok if some email are lost?
2. is it ok if some email are sent twice?

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

1. We relied on container managed transaction and if for some reason the email can not be sent, we decided to rollback the JMS transaction; the message would be redelivered later by JMS and an new attempt to send the message was done.

2. If the JMS message delivery transaction failed after the email was sent (e.g. because of a problem with JMS), the transaction would be rolled back automatically and the message was redelivered later. In this case, the email was sent twice because STMP is not transactional.

3. Even if the email can be sent (from point of view of code), the SMTP server can still have problem later. In this case, the JMS have been delivered and consumed, so we had no way to know which email had been processed and how to re-send them manually.

But we were already using JMS. I would not introduce JMS just for that given that the main argument is that JMS is transactional, but SMTP isn't anyway.

I would go for something lighter -- possibly with a ThreadPool -- and store the state in a database to know which email need to be sent or has been sent. If there are some problem, you can look at the database and take the ad-hoc decisions.

回答3:

I know that this reply is very late to this dicsussion, but I hope it will still be valuable for folks seeking info on integrating ActiveMQ and Tomcat.

I've had many people ask me for help with issues they have had integrating ActiveMQ and Tomcat so I decided to write some articles about it. Not only is this topic covered in ActiveMQ in Action (see chapter 8), but I also published a series of articles on it titled ActiveMQ and Tomcat: Perfect Partners. Hopefully people will find this helpful.

回答4:

I would go for a persistent JMS (I have used only WLS JMS and Websphere MQ so can't compare AQ vs JBoss, whichever offers a better guarantee for delivery). Also, I would seriously consider making the email engine a completely separate application, depending on how much you expect the traffic to grow.