We use MRG-M here too, and we are running in trouble sometimes with this confuse flow-to-disk implementation.
What we expect to have, to replace it, it's something like a real 'queue-on-disk' with parameters like current implementation of flow-to-disk have (max messages/bytes on memory, max messages/bytes on disk file, etc). On Sun, Jul 22, 2012 at 5:31 PM, Jakub Scholz <[email protected]> wrote: > 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] > >
