Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of cgsmcmlxxv@gmail.com
 designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGxYWpZWc3NhZc4a5R0rCSarC+JCZ=nXaf5zBq_QbyUZcRMuOg@mail.gmail.com>
References: 
 <CAGxYWpZtVcfmcUSjwSA6RYdEagkYYPih_yikGNLEpxu2yr1Z5Q@mail.gmail.com>
	<CAKrexVLYf8cmb6YvW=G-nzKeA=wKYvZXvnnfAt_uNvZRv3roZw@mail.gmail.com>
	<D48E725D-9F72-4A82-B4B0-8B74E329C053@apache.org>
	<CAGxYWpZWc3NhZc4a5R0rCSarC+JCZ=nXaf5zBq_QbyUZcRMuOg@mail.gmail.com>
Date: Mon, 20 Aug 2012 12:20:44 +0200
Message-ID: 
 <CAKrexVJDjK_ergK-0HQyiEL+f7KU25ocag-Ht-cR1FnGAneuJw@mail.gmail.com>
Subject: Re: couchdb returning truncated JSON
From: CGS <cgsmcmlxxv@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00235429d190d5628004c7afdc68

--00235429d190d5628004c7afdc68
Content-Type: text/plain; charset=ISO-8859-1

The package from Erlang Solutions repository is built with wxwidgets and
java connectivity and that's why the package requires x11-common and
java-common. For CouchDB neither of them is necessary.

CGS


On Sun, Aug 19, 2012 at 7:18 PM, Tim Tisdall <tisdall@gmail.com> wrote:

> That's strange...  I'm using erlang-dev from the Debian 6 repository.
> I see that there's a debian repository run by erlang-solutions.com but
> it's in a different format than the main Debian repository.  If I try
> to install "erlang" from the main repository or "esl-erlang" from the
> erlang-solutions repository, apt wants to install a whole host of
> packages I really don't want installed such as "x11-common" and
> "java-common".  "erlang-dev" seems to have just installed the bare
> necessities to compile and install the couchdb project.
>
> On Sun, Aug 19, 2012 at 8:13 AM, Robert Newson <rnewson@apache.org> wrote:
> >
> >
> > A full view response should always be valid JSON, so that does point
> towards a bug in CouchDB assuming the response output you posted is
> verbatim what CouchDB returned. Can you reproduce this reliably?
> >
> > Oh, and unrelated to the bug itself, but R14A is a beta release, you
> should upgrade.
> >
> > B.
> >
> > On 19 Aug 2012, at 11:05, CGS wrote:
> >
> >> I don't suppose the problem is coming from CouchDB, but from your
> external
> >> environment which has a limited number of characters per line,
> truncating
> >> the message if more. It happened to me in few occasions (Linux terminal
> >> truncated my message because it was single line - line end was
> translated
> >> as "\n" inside the message, so, no real line break was actually
> registered).
> >>
> >> CGS
> >>
> >>
> >> On Sun, Aug 19, 2012 at 1:46 AM, Tim Tisdall <tisdall@gmail.com> wrote:
> >>
> >>> I have a script where I query a view for multiple entries of data.
> >>> I'm doing it in batches of 1000.  It works fine multiple times and
> >>> then suddenly it returns a result that doesn't properly parse as JSON
> >>> because it's missing some content at the end (not sure how much, but
> >>> it's at least missing the final bracket to make it complete).
> >>>
> >>> My logs don't point out any problem...
> >>>
> >>> [Sat, 18 Aug 2012 22:14:08 GMT] [debug] [<0.26768.3>] 'POST'
> >>> /app_stats/_design/processing/_view/blanks {1,0} from "127.0.0.1"
> >>> Headers: [{'Content-Length',"14010"},
> >>>          {'Content-Type',"application/json"},
> >>>          {'Host',"localhost"}]
> >>> [Sat, 18 Aug 2012 22:14:08 GMT] [debug] [<0.26768.3>] OAuth Params: []
> >>> [Sat, 18 Aug 2012 22:14:08 GMT] [debug] [<0.26768.3>] request_group
> >>> {Pid, Seq} {<0.20450.3>,95240673}
> >>> [Sat, 18 Aug 2012 22:14:08 GMT] [info] [<0.26768.3>] 127.0.0.1 - -
> >>> POST /app_stats/_design/processing/_view/blanks 200
> >>>
> >>> Here's what I received from couchdb:
> >>>
> >>> HTTP/1.0 200 OK
> >>> Server: CouchDB/1.2.0 (Erlang OTP/R14A)
> >>> ETag: "B25M1ITCCF4RKMFE87QMQ1N3M"
> >>> Date: Sat, 18 Aug 2012 22:22:10 GMT
> >>> Content-Type: text/plain; charset=utf-8
> >>> Cache-Control: must-revalidate
> >>>
> >>> {"total_rows":14829491,"offset":12357523,"rows":[
> >>>
> >>>
> {"id":"34049664743","key":"34049664743","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34049674790","key":"34049674790","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34049683784","key":"34049683784","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34049710675","key":"34049710675","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>      [  **  SNIP **  ]
> >>>
> >>>
> {"id":"34082476762","key":"34082476762","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34082494494","key":"34082494494","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34082507402","key":"34082507402","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34082533553","key":"34082533553","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34082612840","key":"34082612840","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34082621527","key":"34082621527","value":[{"start_date":"2012-08-05","end_date":null}]},
> >>>
> >>>
> {"id":"34082680993","key":"34082680993","value":[{"start_date":"2012-08-05","end_date":null}]}
> >>>
> >>> it seems to consistently truncate at a point where the next character
> >>> should either be another comma or a closing square bracket (to close
> >>> the "rows" array).
> >>>
> >>> I tried changing the script to do batches of 100 and it seems to be
> >>> running without problems.  Shouldn't there be some sort of error,
> >>> though?
> >>>
> >
>

--00235429d190d5628004c7afdc68--