Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: couchdb returning truncated JSON
From: Robert Newson <rnewson@apache.org>
In-Reply-To: 
 <CAKrexVLYf8cmb6YvW=G-nzKeA=wKYvZXvnnfAt_uNvZRv3roZw@mail.gmail.com>
Date: Sun, 19 Aug 2012 13:13:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D48E725D-9F72-4A82-B4B0-8B74E329C053@apache.org>
References: 
 <CAGxYWpZtVcfmcUSjwSA6RYdEagkYYPih_yikGNLEpxu2yr1Z5Q@mail.gmail.com>
 <CAKrexVLYf8cmb6YvW=G-nzKeA=wKYvZXvnnfAt_uNvZRv3roZw@mail.gmail.com>
To: user@couchdb.apache.org


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).
>=20
> CGS
>=20
>=20
> On Sun, Aug 19, 2012 at 1:46 AM, Tim Tisdall <tisdall@gmail.com> =
wrote:
>=20
>> 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).
>>=20
>> My logs don't point out any problem...
>>=20
>> [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
>>=20
>> Here's what I received from couchdb:
>>=20
>> 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=3Dutf-8
>> Cache-Control: must-revalidate
>>=20
>> {"total_rows":14829491,"offset":12357523,"rows":[
>>=20
>> =
{"id":"34049664743","key":"34049664743","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34049674790","key":"34049674790","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34049683784","key":"34049683784","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34049710675","key":"34049710675","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>      [  **  SNIP **  ]
>>=20
>> =
{"id":"34082476762","key":"34082476762","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34082494494","key":"34082494494","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34082507402","key":"34082507402","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34082533553","key":"34082533553","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34082612840","key":"34082612840","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34082621527","key":"34082621527","value":[{"start_date":"2012-08-05=
","end_date":null}]},
>>=20
>> =
{"id":"34082680993","key":"34082680993","value":[{"start_date":"2012-08-05=
","end_date":null}]}
>>=20
>> 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).
>>=20
>> 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?
>>=20