I'm writing an application in which -

Many users can subsribe to posts made by another users.

So for a single publisher there can be many subscribers.

When a message is posted by an user X, all users who have subscribed to messages of User X will be sent an email.

How to achieve this ? I'm thinking of using publish-subscribe pattern.

And then I came through JMS. Which is the best JMS implementation to use according to your experience ?

Or else what else solution do you propose to the given problem ?

Shall I go for a straight-forward solution ?: User x posts a message, I find all users (from database) who subscribe to user x and then for every user, I call the sendEmail() method.

[EDIT] My intention here is not to send-emails. I'm really sorry if it wasn't clear. I also have to send kind of system-notifications apart from Email to all subscribers.

Right now, I've implemented the email-sending as a threadPool

  • Would all depend on the amount of emails you expect to send. Using sendEMail for every single mail may become slow at some point and you could use some bulk email system since the content of the mail would be the same for all recipients anyway. Oct 26, 2013 at 18:09
  • xmpp is also commonly used for this kind of thing. Facebook chat is based on it Google chat is or used to be.
    – Sarien
    Oct 26, 2013 at 19:47
  • @thorstenmüller thanks for replying. Please see my updated question. I'm sorry the intention was not clear earlier. Oct 26, 2013 at 19:54

2 Answers 2


Hope you are not looking for a platform specific solution

If Yes, your requirement highlights a pub/sub pattern. I handled the same using RabbitMQ which has specific support for Pub/Sub scenario.

Without going in to granular details, to give you an idea on RabbitMQ's pub/sub model

It has something called "exchange" in addition to "producer","queue", & "consumer"

The core idea on this messaging model is that the producer never sends any messages directly to a queue. A quite often the producer doesn't even know if a message will be delivered to any queue at all. The producer can only send messages to an exchange. An exchange receives messages from producers and the other side it pushes them to queues.

It supports different exchange types to satisfy your various needs - direct, topic, headers and fanout.

This means greater flexibility to de-couple core MQ functionality from the business logic, which you may want to impose on message formats/delivery/retry logic

I used "topic" exchange type which supports message routing/filtering just by looking at message name/title.

To give you a best use of this logic - I had a weird requirement (on pub/sub model) to maintain the list of active subscribers , which I managed to get it done by introducing a heartbeat (topic based) message on the same queue

For the said reasons, and high accuracy on message delivery, and good performance results of supported AMQP protocol, I felt quite happy about my choice

Disclaimer : I am not advocating here that RabbitMQ is the only choice, but sharing this as my nice experience with a smart solution. There are quite few pub/sub solutions out there in the market.

I also found WAMP interesting while exploring various options,but didn't use it for any commercial implementation


I agree with Sarien in that XMPP can be used for the purpose. XEP-0060 - Publish / Subscribe does exactly what you are trying to do... It can send notifications to the subscribers, as well as the payload (on request, or as soon as it is generated). You will have to look deeper though to see if this fits your needs...

Hope it helps.

  • do you mean to say that - I split my application in 2 parts and make one XMPP server and large number of xmpp-clients and then push notifications from XMPP server to the clients, which will further create system-notifications & send emails ? Oct 28, 2013 at 14:09
  • What I mean is that when you have an XMPP server, you do not have to do anything: XMPP offers in-band registration/addition of users programatically. XMPP offers creation of publish nodes to its users. XMPP offers subscription to published nodes to its users. XMPP pushes the changes/notifications automatically to all subscribers. Once you have the notifications from the server, do whatever you want to do with these. You will not have to take care of adding users, keeping track of changes, sending notifications. Install XMPP server and create a JS client that works your way... Hope I am clear. Oct 28, 2013 at 15:22
  • there's no JS client, it's all server-side. For e.g. someone follows me, whenever I make a status-update all other users (even not logged in) will be sent a system-notification and an email-notification. The requirement isn't about a chat-notification system, please let me know if it appears like. Oct 28, 2013 at 17:28
  • I am sorry, what exactly do you mean by system-notifications, even with user not logged in? For email too, user has to login to his email-service... Do you want to say that the system will update the subscribed user once he logs in? What I have mentioned is not chat notifications! If you look at XMPP's XEP-0060 Publish / Subscribe it does exactly what you require: Many users can subsribe to posts made by another users. So for a single publisher there can be many subscribers. When a message is posted by an user X, all users who have subscribed to messages of User X will be sent an email. Oct 28, 2013 at 21:13
  • I must add that all of the things that I have mentioned above can be done sevrer-side. Also, if the answer to the above question is a yes, you are going right towards XMPP PubSub... Oct 28, 2013 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.