Hi, I'm trying to understand some of the finer details of the queue size limits / policies, specifically in the context of a 0.16 cluster (I know 0.16 is a bit old now, but the relevant config options don't appear to have changed).
I have, for example, a number of queues configured like: ... --durable --file-size=512 --file-count=8 --limit-policy=flow-to-disk But I've now been bitten by the "expected behaviour" described in QPID-3286<https://issues.apache.org/jira/browse/QPID-3286> a few times. As I understand it now, the above applies no limits to the queue in RAM, but forces all messages to be written to the journal (aka persistent store), and limits that store to ~256MB. So on some occasions, the journal limit is exceeded on one broker, but not the others, forcing that broker out of the cluster. Since I want all messages for the queue in question to be durable, and I've limited the journal to ~256MB, it seems pretty clear (correct me if I'm wrong) that I should also set the --max-queue-size config to ~256MB too. So, here's my questions: 1. Is this risky in terms of RAM? I ask this, because the --max-queue-size help text says: "Maximum in-memory queue size as bytes". Is it possible, therefore, that qpidd might allow 256MB of RAM for each queue, possibly exhausting RAM, thrashing swap space etc. Or does qpidd apply some other total-size-of-all-queues / RAM limits? 2. What should I set the --limit-policy to? Since I'm making all messages durable, they are all already on disk so flow-to-disk is kind of redundant for me (assuming this is the same store that flow-to-disk refers to?). So I think the policy here should be reject instead (the ring* policies are certainly not what I want). Is my thinking correct? Thanks :) Paul Colby. ---- http://colby.id.au
