Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <5ECBD9A9-1D4E-4841-8C54-4351A565DAEC@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <8CD75D2A-F8EB-451C-B10A-899461BE2CEF@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: replication patches and new _ensure_full_commit feature
Date: Tue, 25 Aug 2009 10:13:40 -0400
References: <8CD75D2A-F8EB-451C-B10A-899461BE2CEF@apache.org>

+1

On Aug 24, 2009, at 11:26 PM, Adam Kocoloski wrote:

> Hi all, I committed a good bit of replication-related code today and  
> wanted to check with the list regarding the 0.10 branch.  Here's  
> what I changed ..
>
> one flat-out bugfix,
> r807308, r807354: more precise and accurate calculation of  
> replication progress
>
> one new feature that could be classified as a bugfix depending on  
> your point-of-view,
> r807342, r807345: follow 302 redirects during replication
>
> and two significant performance improvements (thanks rnewson for all  
> the stress testing):
> r807320, r807360: checkpoint at most once per 5 seconds
> r807208, r807459, r807461: minimize the number of full commit  
> operations
>
> There's another new feature hiding in that last set of commits,  
> namely the ability to do a restricted full commit
>
> POST /db/_ensure_full_commit?seq=N
>
> which guarantees that everything up to and including update_seq N  
> will be synced to disk.  This is a weaker guarantee than a vanilla  
> _ensure_full_commit, and as a result it can be much faster in  
> certain situations (e.g. replication from a server experiencing a  
> heavy batch=ok write load).
>
> I'd like to merge all of these into the 0.10 branch if that abides  
> by our release policies. Best,
>
> Adam