That's right Ted. You know about our issues. This is a thing that will help all qpidd users, and also could be 'platform-independent' on top of a high-performance disk I/O layer (like Tcp I/O layer).
On Mon, Jul 23, 2012 at 6:13 PM, Ted Ross <[email protected]> wrote: > On 07/22/2012 06:33 PM, Virgilio Fornazin wrote: > >> 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). >> >> I think this is the right way to think about it. What we have is a > store that is optimized for journaling (write-only) performance to support > message persistence. Flow-to-disk is a completely different use case and > should be implemented as a separate feature. The primary design goal > should be to have a memory footprint that is not correlated to the queue > size. > > -Ted > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
