From dev-return-10067-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Jun 02 16:59:03 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 24394 invoked from network); 2 Jun 2010 16:59:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Jun 2010 16:59:02 -0000 Received: (qmail 3912 invoked by uid 500); 2 Jun 2010 16:59:02 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 3865 invoked by uid 500); 2 Jun 2010 16:59:02 -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 3857 invoked by uid 99); 2 Jun 2010 16:59:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 16:59:02 +0000 X-ASF-Spam-Status: No, hits=-1996.4 required=10.0 tests=ALL_TRUSTED,FS_REPLICA X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 16:58:59 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o52Gwbil011361 for ; Wed, 2 Jun 2010 16:58:38 GMT Message-ID: <24765134.136301275497917851.JavaMail.jira@thor> Date: Wed, 2 Jun 2010 12:58:37 -0400 (EDT) From: "Randall Leeds (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Commented: (COUCHDB-782) Restarting replication In-Reply-To: <5653579.133941275494617759.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/COUCHDB-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874659#action_12874659 ] Randall Leeds commented on COUCHDB-782: --------------------------------------- I've run into this problem, too. Couch uses the URI of the source and destination to determine the id for the document which stores replication checkpoints. A while back I proposed adding a uuid to each database that does not get replicated and could uniquely identify each replica. No one seemed to think this was important enough, but I'd be happy to do the work. > Restarting replication > ----------------------- > > Key: COUCHDB-782 > URL: https://issues.apache.org/jira/browse/COUCHDB-782 > Project: CouchDB > Issue Type: Bug > Components: Replication > Affects Versions: 0.10 > Environment: Ubuntu, 9.10 > Reporter: Till Klampaeckel > > So we had to restart replication on a server and here's something I noticed. > At first I restarted the replication via the following command from localhost: > curl -X POST -d '{"source":"http://localhost:5984/foo", "target":"http://remote:5984/foo"}' http://localhost:5984/_replicate > In response, futon stats: > W Processed source update #176841152 > That part is great. > Last night I did not have immediate access to the shell so I restarted replication from remote (through curl on my mobile): > curl -X POST -d '{"source":"http://user:pass@public.host:5984/foo", "target":"http://remote:5984/foo"}' http://user:pass@pubic.host:5984/_replicate > The response in futon this morning: > W Processed source update #1066 > ... and it kept sitting there like it was stalled and only continued in smaller increments. > I restarted CouchDB and restarted from localhost - instant jump to 176 million. > I'm just wondering what might be different accept for that one is against the public interface, vs. localhost. I'd assume that replication behaves the same regardless. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.