I have looked into several message queues as referenced in this link. Several of the larger and more popular ones are in memory only.
I can understand the need for this in some situations however in a large architecture this makes little sense to me. For instance if I have a series of work that needs to be performed such as user calculations, object updates, info refresh, and then the MQ crashes all work is lost.
If this is imperative the lost work could be loaded again however why would I want to?
I would imagine there is vital and then regular pieces of information however if I use a non-persistence MQ then all my data would be regular and that doesn't seem valid.
Best Answer
Consider a client that wishes to push a message to a queue. The queue manager would typically send a message acknowledgement to the client to signify that the message was successfully delivered to the queue. A persistent MQ would first need to write the message to persistent storage which for most storage media would be an expensive IO operation relative to memory operations.
The cost of persistence in message queues is a factor that may play into a decision to go for non-persistent message queues.
The drawbacks of non-persistent message queues are essentially that you must contend with potential data loss in the event of a partial or complete outage of a machine, however this isn't always necessarily true if you opt for distributed non-persistent message queues in a cloud based infrastructure across multiple data centers. This would ensure that even a complete data center outage for a cloud hosting provider would not result in loss of the message, at least one other node is guaranteed to still have the message.
Of course if potential for message loss is not a serious concern for your application then you don't even need such a complex solution. It becomes a comparison of quality attributes, Performance vs. Reliability.