couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Replication: stalled?
Date Tue, 01 Mar 2011 19:44:11 GMT
I mentioned the undeclared dependency on eunit and the fact that
Debian packaged it separately some months ago. In addition, I passed a
patch to mochiweb (where the dependency comes from) to fix it, but
failed to chase it up.


On 1 March 2011 19:34, Adam Kocoloski <> wrote:
> On Mar 1, 2011, at 2:26 PM, Filipe David Manana wrote:
>> On Tue, Mar 1, 2011 at 6:54 PM, Wayne Conrad <> wrote:
>>> On 03/01/11 03:15, Filipe David Manana wrote:
>>>> You can also try the new replicator that landed recently into trunk
>>>> (from where 1.2 will be cut from), it adds more parallelism so you'll
>>>> likely see a better performance:
>>> Version 1.2.0ac052866-git replicates my ginormous documents with panache.
>>>  My test-case-de-jeur is a document with 32,700 attachments, 4k each.
>>>  Inserting 100 attachments at a time, the document gets inserted into the
>>> source database in 42 seconds.  The destination database is pulling the
>>> changes so fast I can't measure the latency by refreshing futon: The moment
>>> I'm done adding the last attachment to the source database, it appears in
>>> the destination database.  Outstanding!
>>> I had only one small issue building it: on Debian, the package
>>> "erlang-eunit" is required to run "make check."  Is that worth mentioning in
>>> the DEVELOPER file?
> I'm a bit surprised by this one, I thought we had figured out how to avoid that.  Bob?
>>> Before I put it in production, "make check" reports some failures.  Do these
>>> matter?
>> No they're related to the vhost and OS daemon features. The former was
>> fixed this morning I believe, while the later happens often but not
>> always. They're completely unrelated to the replicator, rest assured
>> :)
> Yes, the errors in 173 have happened in each of the last four CI builds (50-53) for R14B01:
> I've discussed them with Paul and one of these days we'll get around to making that test
less timing-sensitive.
> Thanks for the detailed report Wayne.  Cheers, Adam

View raw message