Hi Carl, I definitely do not see any problem in sacrificing the features like LVQ. I'm not so sure about browsing ... do we need to disable browsing to have the real flow to disk queue? If yes, what about multiple consumers connected to the same queue or acknowledging the messages out of order?
Regards Jakub On Mon, Jul 23, 2012 at 9:20 PM, Carl Trieloff <[email protected]> wrote: > On 07/23/2012 07:40 AM, Jakub Scholz wrote: >> Yes, the use of flow-to-disk queues unfortunately doesn't solve the >> memory issue on 100%. It just decreases the memory consumption, so the >> point when the broker runs out of memory is postponed a bit. >> >> > > we actually need 'real' flow to disk queue here. > > Would a queue type that does not allow browsing for example, but flushes > everything to disk and only supports FIFO cover your use case. Issue is > when you flush everything to disk, any non FIFO operation becomes very > expensive > > Carl. > > --------------------------------------------------------------------- > 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]
