From dev-return-9185-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Mar 17 22:37:50 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 37917 invoked from network); 17 Mar 2010 22:37:49 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Mar 2010 22:37:49 -0000 Received: (qmail 17990 invoked by uid 500); 17 Mar 2010 22:37:49 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 17938 invoked by uid 500); 17 Mar 2010 22:37:49 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 17585 invoked by uid 99); 17 Mar 2010 22:37:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Mar 2010 22:37:48 +0000 X-ASF-Spam-Status: No, hits=-1045.8 required=10.0 tests=ALL_TRUSTED,AWL,FS_REPLICA X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Mar 2010 22:37:47 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id BAFF5234C48D for ; Wed, 17 Mar 2010 22:37:27 +0000 (UTC) Message-ID: <1882272857.326301268865447764.JavaMail.jira@brutus.apache.org> Date: Wed, 17 Mar 2010 22:37:27 +0000 (UTC) From: "Randall Leeds (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Created: (COUCHDB-704) Replication can lose checkpoints MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Replication can lose checkpoints -------------------------------- Key: COUCHDB-704 URL: https://issues.apache.org/jira/browse/COUCHDB-704 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 0.12 Reporter: Randall Leeds Priority: Minor When saving replication checkpoints in the _local/ document the new entry is always pushed onto the _original_ "history" list property that existed at the start of the replication. When any number of things causes the checkpoint to be written to only one of the databases the head of the history list gets out of sync. Subsequent attempts to start this replication must start from the latest common replication log entry in the _original_ history, as though this replication never occurred. A better idea is to push every checkpoint onto the history instead of replacing the head on each save. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.