Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of fred.moore77@gmail.com
 designates 209.85.220.216 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=LEd9cQkovDRk0KMiya9aYl9sJUTuLnw3J2+i2kw5XABmXdsuzGgBwvTrrHDemzgBSg
         FyXY5sCR9+0ZEbdOeW0efOvGQgXYV45Rd0/8Fh3acwrLsG6iGxwqJnPZZNk0Oxze4Qjp
         zp4gHVrOBrFVdp1XiAXsCQQ8I44FKx4R1YdrA=
MIME-Version: 1.0
Date: Fri, 22 Jan 2010 19:16:03 +0100
Message-ID: <69b2d60e1001221016i53aeb247lea957449895b2814@mail.gmail.com>
Subject: How to configure 5.3 broker over KahaDB to support lots of unconsumed
	persistent msgs?
From: Fred Moore <fred.moore77@gmail.com>
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=001517476248fa6d38047dc4cff0

--001517476248fa6d38047dc4cff0
Content-Type: text/plain; charset=ISO-8859-1

Hi folks,

we have a 5.3 embedded KahaDB based broker with just a VM connector on it
(see activemq.xml here http://pastebin.com/f492ec856), our producers
continuously send persistent messages while the consumers run intermittently
(because they are bound to the availability of an external
and intermittently available service).

For this reason we require to be able to accommodate many persistent
messages onto disk, waiting for the superlazy consumers to get them and
without slowing producers down.

We have no constraints at all on disk space utilization.

All we have done so far is to inhibit producer flow control
(producerFlowControl="false") but the behavior it's still a bit unstable and
we quickly get OOM exceptions when we stop consumers.

We're not able to figure out which other parts of activemq.xml configuration
need to be tuned.

Can anyone provide pointers/samples?

Here are a few questions to get us started:

1\ What is the real role played by memoryLimit in
   <policyEntry topic=">" producerFlowControl="false" memoryLimit="1mb">
   <policyEntry queue=">" producerFlowControl="false" memoryLimit="1mb">

2\ <systemUsage> has been left unspecified: what shall we configure to get a
"don't care how much disk is used" behavior?

3\ We kept default message cursor settings, under the assumption that they
were the right ones for our scenario with persistent messages and deep
queues: is this right?

Cheers,
F.

PS: ...if you believe this is a duplicate of "OOM with high KahaDB
indextime" thread, let's keep that one alive and not this.

--001517476248fa6d38047dc4cff0--