Hi Kevin, there are a few possibilities, one of which is that the replicator gets confused about the expected length of the response body. My recollection is that the replicator in 1.0.x and 1.1.x ignores the actual value of the content-length header when pulling an attachment and instead expects to read the number of bytes specified in the _attachments metadata in the document (I'm not sure about the behavior of the new replicator in 1.2 in this respect). Throw attachment compression into the mix and things can get tricky. For example, it might be the case that the _attachments metadata contains the identity length of the attachment but that the attachment is ultimately served in compressed form during the replication.
As far as workarounds go, can you initiate the replication from the source server and specify the local database name as the source? You'll use a rather different code path. Adam On Saturday, September 17, 2011 at 6:30 PM, Dave Cottlehuber wrote: > Sorry Kevin, my apologies, only read ½ of that email - clearly quoting > alone isn't enough to explain this. > > What version(s) or buidls of CouchDB are involved? > Also, are you able to post some of the logs online in debug mode? > > Thanks > Dave > > On 18 September 2011 10:17, Dave Cottlehuber <[email protected] > (mailto:[email protected])> wrote: > > On 17 September 2011 09:40, Kevin R. Coombes <[email protected] > > (mailto:[email protected])> wrote: > > > I am trying to replicate a couch database from one Windows machine to > > > another. Replication halts with an error when it gets to an attachment of > > > the design document. The error message in the (local) log file just before > > > the stack dump says > > > > > > [Fri, 16 Sep 2011 21:22:57 GMT] [error] [<0.813.0>] streaming att. ended > > > but > > > more data requested {1316,208177,498001} > > > [Fri, 16 Sep 2011 21:22:57 GMT] [info] [<0.813.0>] request for > > > "_design%2Fbasic/docs.html" timed out, retrying in 0.5 seconds > > > > > > The replication was started by sending a POST to the local machine; I am > > > using pull replication from a remote source to the local target. Admins > > > are > > > set up on the local machine, and I provided the admin credentials both as > > > part of the URL starting the replication and as part of the target URL. > > > > > > When I use "curl" from the command line on the local machine to request a > > > file from the remote machine, the command > > > curl [REMOTEDB]/_design%2Fbasic/docs.html > > > returns nothing, while the command > > > curl [REMOTEDB]/_design/basic/docs.html > > > returns the correct file. > > > > > > Clearly, there is something about the encoding of a forward slash as a > > > "%2F" > > > that is confusing both me and at least one of the couch instances involved > > > in this attempt at replication. > > > > > > Can someone tell me [1] what is the underlying source of the problem? and > > > [2] how do I persuade couch to just replicate the design documents > > > properly? > > > > > > Thanks, > > > Kevin > > > > Hi Kevin, > > > > I assume you're driving replication via curl, in a cmd.exe shell, and > > that things work via futon. > > > > [1] is likely quoting which is not obvious on windows > > http://wiki.apache.org/couchdb/Quirks_on_Windows has some examples on > > fixing this. Using curl -v should show you what the actual text sent > > through to CouchDB is. > > > > [2] depending on whether you're running in admin party or not, you may > > need to include username:password@couch for ddocs to replicate. > > > > A+ > > Dave
