incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <adam.kocolo...@gmail.com>
Subject Re: "%2F" problems
Date Sun, 18 Sep 2011 01:07:57 GMT
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 <dave@muse.net.nz (mailto:dave@muse.net.nz)>
wrote:
> > On 17 September 2011 09:40, Kevin R. Coombes <kevin.r.coombes@gmail.com (mailto:kevin.r.coombes@gmail.com)>
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



Mime
View raw message