Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
From: Robert Samuel Newson <rnewson@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Truncated response when POST a _changes query
Date: Wed, 3 May 2017 23:14:17 +0100
References: <8b20bc92-ddd9-ad8c-c4d8-495e6b014daf@linux.vnet.ibm.com>
 <1264149608.68723.1493840543865.JavaMail.Joan@RITA>
To: dev@couchdb.apache.org,
 Joan Touzet <wohali@apache.org>
In-Reply-To: <1264149608.68723.1493840543865.JavaMail.Joan@RITA>
Message-Id: <41386FC4-BDB5-4786-A758-F037625A8EF5@apache.org>
archived-at: Wed, 03 May 2017 22:14:25 -0000

Agree with Joan, the most important thing is the log files.

If couchdb can send an error in the response, it will (a 413 or 404, =
etc, etc).

But if we've already started the response and _then_ encounter an error, =
we can't send any useful information in the response, we have to close =
the connection. When that happens, we log the error. You should find =
that the request id you got matches something in the logs.

I expect it's a function_clause or case_clause, something of that =
nature, and possibly indicating an unanticipated malformed request.

Logs pls.

B.

> On 3 May 2017, at 20:42, Joan Touzet <wohali@apache.org> wrote:
>=20
> Hi Nasser,
>=20
> Thank you for the report.
>=20
> Are you running against a single node or a clustered CouchDB 2.0
> install? If clustered, how many nodes, and are they all running on
> the same machine, or different machines? Have you changed any
> settings in the ini files?
>=20
> What sort of database do you have? Does it have any conflicted
> versions in it?
>=20
> Do you have any CouchDB logfiles from when the error occurs? Do any
> of them show anything useful? You can set the logging level to debug
> to gather additional information.
>=20
> Please don't email logfiles directly to this list; you can share them
> with a service like gist.github.com, pastebin.com or paste.apache.org
> instead.
>=20
> Finally, have you tried running against our current master rather
> than the released 2.0 version? We've fixed a lot of bugs since then,
> and it's possible this bug has already been resolved as the result of
> an unrelated change.
>=20
> -Joan
>=20
> ----- Original Message -----
> From: "Nasser Ebrahim" <enasser@linux.vnet.ibm.com>
> To: dev@couchdb.apache.org
> Sent: Wednesday, 3 May, 2017 1:48:06 PM
> Subject: Truncated response when POST a _changes query
>=20
> Hello,
> While doing the Cloudant swift test, we are getting truncated response=20=

> when POST a _changes  query  to the CouchDB with document ID [=20
> =
<http://docs.couchdb.org/en/2.0.0/api/database/changes.html>http://docs.co=
uchdb.org/en/2.0.0/api/database/changes.html].=20
> We are getting the failure very frequent while doing the test from a=20=

> swift client on Linux with couchDB 2.0 as server. We compared the TCP=20=

> stream of the passing and failing case and the request is exactly the=20=

> same. Hence, we believe there is something going wrong while =
processing=20
> the request on the CouchDB side as we are getting the truncated =
response.
> Another interesting observation is that if we introduce a small delay=20=

> (sleep) before writing the request body on the swift client side, the=20=

> test is passing (the response from CouchDB is proper). Hence, we think=20=

> this could be a timing related issue on the CouchDB side.
> While doing the same Cloudant swift test from Mac OS, we are observing=20=

> the failure very rarely. We believe it could be the change in timing=20=

> which hide the issue similar to when we introduce the delay while=20
> testing on Linux.
> The response from the CouchDB has three chunks. The first chunk is a=20=

> standard text {"results=E2=80=9D:[, the second chunk is the actual =
response and=20
> the last chunk is the standard stream terminator sequence. In the=20
> failing case, we are getting only the first chunk. Hence, it seems the=20=

> failure occurred while processing the response on the CouchDB side.
> We have taken the CouchDB trace and Wireshark trace from the server =
side=20
> and we could confirm that the request is exactly the same between the=20=

> passing and failing case where as the response is truncated on the=20
> CouchDB side during the failure.
> Please let us know whether you are aware of any such issues on the=20
> CouchDB side and what diagnostic documents are required for you to do=20=

> the analysis.
> Thank you,
> Nasser Ebrahim