On Tue, Mar 1, 2011 at 2:34 PM, Adam Kocoloski <[email protected]> wrote: > On Mar 1, 2011, at 2:26 PM, Filipe David Manana wrote: > >> On Tue, Mar 1, 2011 at 6:54 PM, Wayne Conrad <[email protected]> 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: >>>> >>>> http://s.apache.org/KsY >>>> >>>> >>>> https://github.com/apache/couchdb/commit/34eb4175f8547546cd76fbeb006421020cbf0d71 >>> >>> 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: > > http://jenkins.cloudant.com/job/CouchDB-trunk-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 > >
Yeah, I tried rewriting this one in shell but got stuck on how to get the script to close when stdin was closed. If anyone knows a bit of shell foo that can do that, feel free to let me in on the secret.
