Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Highly related Nodejs: many clients requests through one socket

I'm investigating a robust message passing system for this application of mine. The easyest solution would be Redis pub/sub (it's simple, effective and I'd also use Redis for caching) but as I understand it, publishing is a "one shot" operation only to actually subscribed clients. Whoever subscribes after the publishing, does not get the message. I'd like to be able to "stash" unreceived messages for a while, so if I reconnect to the channel I'd get back the messages I've not received. I know that systems like ActiveMQ with the ack and permament queue mechanism would solve this issue easily, but I'm wondering if there could be a simpler solution/approach. What do you think?

share|improve this question

migrated from May 20 '11 at 6:33

This question came from our site for professional and enthusiast programmers.

use a second permanent database. Use redis for real time sending of messages through pub/sub but also store all your messages in a permanent database (couch / mongo).

Then when a Client / User reconnects load all messages from the real database and put them in the redis pub/sub system.

You will need this anyway to implement a history / past events system.

share|improve this answer
but then that's not pubsub is it? – jcolebrand May 19 '11 at 15:14
@drachenstern >_< It's both. He wants a new user to get previous data that was published before he subscribed. The best way to do this is from a queue / stack. The best way to implement that is a permanent storage database. – Raynos May 19 '11 at 15:27
Yes, it is (in theory) - because the idea is that messages will be re-published on the channel. It won't work anyway, because someone should know which messages have to be popped from the database. We have not this info, beacuse there is no ACK mechanism... – Claudio May 19 '11 at 15:29
Which is no longer pubsub. I'm just saying I think there's a better mechanism in place to do what he wants already, or at least an existing pattern that's better than pubsub. The folks at P.SE tend to be more knowledgeable about patterns than we (or at least are faster to respond with them). I honestly feel he's asking for Atom/RSS – jcolebrand May 19 '11 at 15:30
@Claudio store a message received flag in the database for all users :D – Raynos May 19 '11 at 15:30

You could do this easily with CouchDB. It has a /_changes API that gives you a running history of changes. You can give it a timestamp to get everything since then.

If that doesn't work, you could make a simple queue and save messages yourself. It doesn't have to be the fastest because they are archived.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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