[rar_ram]

> Messages are not guaranteed to be delivered, if the client is running behind on processing messages, newer messages could be dropped.

> Messages are not stored until they are delivered, if no client is available to receive the message, then it is dropped without being sent anywhere.

Not sure in which use cases can I use this ? Doesn't this defeat the purpose of having a message queue.

[sdomino]

Mist isn't intended to be a message queue, its simply a message passer.

Similar to the old question, "if a tree falls in the woods and no one is there to hear it does it make a sound?" Yes; similarly Mist will send a message whether or not anyone is listening, and will keep sending them whether or not the client is prepared to handle them.

[tylerflint]

So to the first question, there's not a transactional layer to guarantee the client handled the message. Once a message is sent to the client, it is assumed the client has a mechanism for queuing messages if it can't keep up.

As to the second, the caveat is basically saying that if a message is broadcast and nobody cares about the message (ie: there aren't any subscriptions) then mist isn't going to store the message anywhere, it just gets dropped.

[rar_ram]

Err, I get that! but I am still wondering on where would I use this ? If I dont need transactional layer or buffering, I could use event listener and dispatcher pattern. Anything more than that, a message queue like ZMQ works. Where does this fit in ?

[tylerflint]

Oh I see. Sorry for the confusion. The initial need was for a rails app to send data model updates to dashboard clients. Later, as our infrastructure became more micro-service-oriented, mist has been used as a place for the dashboard javascript client to subscribe to a centralized event queue. Each micro-service will publish messages to the mist cluster, and the dashboard can respond accordingly.