4 ms·
i'm a bit confused here, so forgive me if i've got something muddled up. were zeromq's queues just in-memory? it was never meant to be reliable in the sense t
by andrewcooke 13y ago
i'm a bit confused here, so forgive me if i've got something muddled up.
were zeromq's queues just in-memory? it was never meant to be reliable in the sense that messages were preserved in a database at each socket, was it?
alternatively, if i am wrong above, and zeromq was reliable / persistent then why did you drop this?
thanks (i've worked on esbs, but not with zmq).
- gnaritas 13y ago> were zeromq's queues just in-memory? Yes. > it was never meant to be reliable in the sense that messages were preserved in a database at each socket, was it? No. It's meant to be a fast inter app messaging protocol, it's not a queue, it simply uses some in memory queues internally. It's not a queue, it's an improved socket library, having MQ in the name was clearly a mistake that he's now corrected.
- sophacles 13y agoOr the whole name 0mq can be read to mean no message queue. Which in context of middleware makes sense
- gnaritas 13y agoIt can be, but it generally isn't, look around the net and you'll see it's pretty clear that most think it's a message queue and it gets thrown into that mix when the topic comes up. People are always having to explain to others that it isn't a queue, that's bad naming of the product.
- rumcajz 13y agoIn ZeroMQ it was in user-space memory. Now it's in kernel-space (TCP rx/tx buffers). That actually makes it a little more reliable as tx buffers are not necessarily dropped when the application fails.