From user-return-22382-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sat Oct 6 09:51:36 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D6D42DC41 for ; Sat, 6 Oct 2012 09:51:36 +0000 (UTC) Received: (qmail 65899 invoked by uid 500); 6 Oct 2012 09:51:35 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 65495 invoked by uid 500); 6 Oct 2012 09:51:30 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 65450 invoked by uid 99); 6 Oct 2012 09:51:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Oct 2012 09:51:28 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of m.bykov@gmail.com designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Oct 2012 09:51:23 +0000 Received: by mail-ie0-f180.google.com with SMTP id e10so5673001iej.11 for ; Sat, 06 Oct 2012 02:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=FfBCId2Oi1p08xpLXT/dcB3J2VmtO8fSy+NbuVyGBLo=; b=fxT6UqufW7AggsgRu0HemnyZlhgZ7vKKTmSUS3bK9ACtIQo/QXkdfWoOJx0cdC4eEW MDHYOseILi/yhy6162OTg0mks24ARggbdZKDeQluMYjHFF+UIYQIu6VQnliLgsk3MDcX fEof1exfPUeuN6/pO0SoaGsRD5eT6e69iZeZl5ZBGjwiZb+jOpZ7oUaadRp12JgfAD+y hyH/7Dn5tnYqKEiikl5RJjkf75nxtMJYMuZrAD8yAHA/8a7UTbCWV/P0q1+VbWHDHKyd kcZ6iPtHvvE3LXiAUDdP0fQTvQmqmJtAmjAcGMDQ5G0eqG6vrmNqMHIKo65IW0BQKHsj logA== MIME-Version: 1.0 Received: by 10.50.187.194 with SMTP id fu2mr3403293igc.63.1349517063267; Sat, 06 Oct 2012 02:51:03 -0700 (PDT) Received: by 10.64.141.77 with HTTP; Sat, 6 Oct 2012 02:51:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Oct 2012 13:51:03 +0400 Message-ID: Subject: Re: replication: lexical error: invalid char in json text From: Michael Bykov To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 2012/10/5 Dave Cottlehuber : > On 5 October 2012 17:51, Dave Cottlehuber wrote: >> On 5 October 2012 16:33, Michael Bykov 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: >>> >>> >>> =3DCRASH REPORT=3D=3D=3D=3D 5-Oct-2012::18:16:23 =3D=3D=3D >>> 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"}}, >>> <<"\r\n413 >>> Request Entity Too Large\r\n>> bgcolor=3D\"white\">\r\n

413 Request Entity Too >>> Large

\r\n
nginx/1.1.9
\r\n\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}]}, >>> >>> >>> >>> -- >>> =D0=9C. >>> >>> 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 > > Actually after reading the HTML bit the issue is more likely with your > nginx config: > > 413 Request Entity Too Large > > I'd still diff _all_docs and then use single doc replication [1] as a > quick test, instead of needing to re-run the whole replication. > > A+ > Dave > > [1]: http://wiki.apache.org/couchdb/Replication#Named_Document_Replicatio= n Hi Dave, Thank you, with _all_docs I've easily got an invalid doc. --=20 =D0=9C. http://diglossa.ru xmpp://m.bykov@jabber.ru