On 07/22/2012 09:31 PM, Jakub Scholz wrote:
We expect the brokers to deliver approximately hundreds of GB of messages per day. Under normal circumstances, most of the messages will be consumed by the clients almost immediately, but in some exceptional situations, they may need to be stored on the broker. And since the performance isn't the biggest issue for us (while on the other hand reliability of the broker is), the flow-to-disk queues kind of help (yes, the headers are still kept in memory).
My point was that in such cases, the memory consumed by the queue is not in any way bounded. It will keep growing as the messages pile up. If the content is a significant part of that (i.e. if the messages are relatively large), then flow to disk can at least slow the growth. I assume that slowed growth is useful in your case?
Although you can always say that we can get HW with more memory or split the load between multiple brokers if necessary, it would still be better if the flow-to-disk queues are replaced by some better alternative.
I certainly agree a better solution is needed. One where the memory required for such queues can be bounded in a reliable fashion, regardless of their size.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
