couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: replication: lexical error: invalid char in json text
Date Fri, 05 Oct 2012 15:51:05 GMT
On 5 October 2012 16:33, Michael Bykov <m.bykov@gmail.com> wrote:
> Hi,
>
> Local couchdb works great, but replication does not work.
>
> Replication worked perfectly several days ago. You can see the correct
> (that was replicated) part of it here:
> http://diglossa.ru:5984/_utils/database.html?greek
>
> Please advice how can I find invalid record in local DB?
>
> I got this in log:
>
>
> =CRASH REPORT==== 5-Oct-2012::18:16:23 ===
>   crasher:
>     initial call: couch_replicator:init/1
>     pid: <0.720.0>
>     registered_name: []
>     exception exit: {worker_died,<0.727.0>,
>                         {{nocatch,
>                              {invalid_json,
>                                  {{error,
>                                       {1,
>                                        "lexical error: invalid char in
> json text.\n"}},
>                                   <<"<html>\r\n<head><title>413
> Request Entity Too Large</title></head>\r\n<body
> bgcolor=\"white\">\r\n<center><h1>413 Request Entity Too
> Large</h1></center>\r\n<hr><center>nginx/1.1.9</center>\r\n</body>\r\n</html>\r\n">>}}},
>                          [{ejson,nif_decode,1,[{file,"ejson.erl"},{line,57}]},
>                           {ejson,decode,1,[{file,"ejson.erl"},{line,38}]},
>                           {couch_replicator_httpc,process_response,5,
>                               [{file,"src/couch_replicator_httpc.erl"},
>                                {line,88}]},
>
>
>
> --
> лю.
>
> http://diglossa.ru
> xmpp://m.bykov@jabber.ru

I'm guessing the underlying issue is replication with source being an
older version of couchdb, or for some reason (e.g. different
spidermonkey or JSON parsing library) is unable to complete parsing
one document, causing the replication to die when only a partial doc
is sent. It could be a lot more informative about where it's at
however. If you're using filtered replication perhaps that may also be
a mode of failure.

Um there are a couple of ways to do this; the simplest is to sort &
then diff the _all_docs list from both DBs, with whatever sensible
tidyup is needed.

Alternatively, I think in either source or destination log (when
you're in debug mode) will show the last successful doc received or
transferred.

A+
Dave

Mime
View raw message