couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R.J. Steinert">
Subject Re: How to configure a limit on simultaneous replications?
Date Mon, 16 Dec 2013 16:13:56 GMT
@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’s weird. What sort of network connection is the replication using?
> Is this over a LAN (WiFi or Ethernet), a wider-range Internet connection, a
> cell network…? 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’re describing sounds like a bug; a dozen
> 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.)
> >
> > —Jens

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message