Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AC0EC10E5B for ; Mon, 16 Dec 2013 16:14:31 +0000 (UTC) Received: (qmail 55150 invoked by uid 500); 16 Dec 2013 16:14:30 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 54678 invoked by uid 500); 16 Dec 2013 16:14:23 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 54656 invoked by uid 99); 16 Dec 2013 16:14:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Dec 2013 16:14:21 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.160.44] (HELO mail-pb0-f44.google.com) (209.85.160.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Dec 2013 16:14:17 +0000 Received: by mail-pb0-f44.google.com with SMTP id rq2so5643235pbb.17 for ; Mon, 16 Dec 2013 08:13:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yoo3ORRmJF/If+sZJy6CafY45EDA2E1dKE9J65qwVG0=; b=NK2MUxdfLosKo9+XBylktMrKcDIJfMePo+UFFlYm+tu/NAFBjdlqeAm/5k+Xpuz/uY xzQCjb2PkPYp6m2mpYm/KrRCgIm6wKaPHfYyzRQ5U3juMPi+VookXPDHEgI4KbhhNVYR b5vsnpBz1sDJFxQkVDO0g3FhFpi+Y6MBJjbZiLo3XlgCg4za9AWuVY+6ednvXk3Tv3Uj d+xoX/4rmurDRdbtY6KLPIZOqATFm1cSFLo/JnbuhxDLc07gWoWv49lWCPzqLmEiWVYP 7bfECgx/k3UV2YdrKU3JgLWD40JBiOs4K/kBXugOv2iS4ZhPRhoNpHwbKE0ObJxgbIWr a4bA== X-Gm-Message-State: ALoCoQmVAa5JTecX2JcH3OGs6w3NSiMcdDYPjeDqWyH84iLWwn7Gip+9e7OAJmT7CMjBLv4jMZf/ MIME-Version: 1.0 X-Received: by 10.68.130.169 with SMTP id of9mr21194492pbb.79.1387210436932; Mon, 16 Dec 2013 08:13:56 -0800 (PST) Received: by 10.68.229.103 with HTTP; Mon, 16 Dec 2013 08:13:56 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Dec 2013 11:13:56 -0500 Message-ID: Subject: Re: How to configure a limit on simultaneous replications? From: "R.J. Steinert" To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=047d7b10cac5538c0704eda91954 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b10cac5538c0704eda91954 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable @Jens We're testing over a strong Internet connection. My laptop for example has no problem doing this replication in the couple of seconds you have also experienced, the Raspberry Pi on the other hand... @Robert Thanks for chiming in. Unfortunately I'm no Erlang expert so I won't be much help. I may however look at writing a replication manager in Javascript, perhaps contributing it to the PouchDB project. On Tue, Nov 26, 2013 at 3:33 PM, Robert Newson wrote: > If you mean the _replicator database then, yes, currently it will > attempt to run all the jobs at once. That is, there is Considerable > Room For Improvement. > > B. > > > On 26 November 2013 19:10, Jens Alfke wrote: > > > > On Nov 26, 2013, at 10:07 AM, R.J. Steinert wrote: > > > >> when CouchDB tries to replicate them all at once, the replications > >> never seem to finish in a dependable fashion. Sometimes some of the > >> databases will finish replicating others will hang for days. Each > database > >> is only a couple dozen KB so these replication processes aren't > managing a > >> whole lot of data. > > > > That=92s weird. What sort of network connection is the replication usin= g? > Is this over a LAN (WiFi or Ethernet), a wider-range Internet connection,= a > cell network=85? Basically the slower / laggier / flakier the network is,= the > more roadblocks are thrown in the way of the replicator. It should still > work reliably, though, so what you=92re describing sounds like a bug; a d= ozen > tiny databases should be able to replicate in a few seconds unless there > are major network issues. > > > > (Disclaimer: I am not familiar with the replicator implementation in > CouchDB itself, although I have implemented compatible replicators so I > know the protocol well.) > > > > =97Jens > --047d7b10cac5538c0704eda91954--