We use Qpid (well, MRG-M) as an interface to our costumers. As such, we have quite limited control over - the amount of messages - the time when the messages are consumed (i.e. does the client connect to consume the messages or not) 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).
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. Regards Jakub On Fri, Jul 20, 2012 at 11:54 AM, Gordon Sim <[email protected]> wrote: > On 07/20/2012 10:22 AM, Jakub Scholz wrote: >> >> While I agree with you that the flow-to-disk queues have a lot of >> problems, I do not think they are totally useless. If you remove them >> without any real alternative, you may block the upgrade path for many >> people using them. At least speaking for my self, it probably would be >> a problem for some of our brokers. > > > Understood. Can you give any more detail of how you use them? i.e. what sort > of scenarios the feature is triggered in? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
