Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4A69E542.3050804@sun.com>
Date: Fri, 24 Jul 2009 17:45:54 +0100
From: Alan Burlison <Alan.Burlison@sun.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090608)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Derby replication failed under heavy load
References: <4A68D775.6020203@sun.com>
 <882C3355DFF9D3468379DD1E8C115FC73986BC3747@EVS-RED.coloflorida.com>
In-Reply-To: 
 <882C3355DFF9D3468379DD1E8C115FC73986BC3747@EVS-RED.coloflorida.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Lawrenson wrote:

> I'm not sure if it's the exact same issue, but I have observed the
> replication failing under heavy load where the replication buffers
> would fill faster than the logs can be shipped to the slave (even
> with fast servers & fast network). I've previously tweaked a copy of
> derby to allow up to 100 buffers (rather than the current max of 10),
> and optimized the various thresholds, but still observed over 80
> buffers being used under high load (this was with 10.4.2.0 on
> Solaris).

I think it is the same issue - I saw an errors in the master log that 
mentioned something about the buffers filling up.  The thing that seems 
to trigger it is doing a number of whole-table deletes, presumably 
because while that's being processed on the slave the master is still 
chugging along writing more log records.

What I don't understand is why the master isn't being throttled if the 
slave can't keep up.

-- 
Alan Burlison
--