couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nasser Ebrahim <>
Subject Re: Truncated response when POST a _changes query
Date Tue, 09 May 2017 09:12:57 GMT
Thank you Joan and Robert for your inputs.

We have tested with latest master of CouchDB and confirmed that the 
problem still exists.

Regarding your questions:

  - We have tested with single node. We tried both client and server on 
the same machine and on different machines and it fails on both the cases.

  - The only changes we made to the ini file are :

     * to enable the logging level to debug.

     * change bind_address to to let CouchDB listen any 
available IP address

     * change port from 5984 to 5988 as 5984 is used by another 
application in that machine.

level = debug

port = 5988
bind_address =

  - We do not have any conflict version of the database in the system.

  - We have collected the CouchDB logs and Wireshark traces from the 
failing and passing cases (with delay while writing request body) and 
uploaded to

Please review the logs and let us know whether they are good enough or 
you need more logs.

  Thank you,
  Nasser Ebrahim

On 5/4/17 3:44 AM, Robert Samuel Newson wrote:
> 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 <> wrote:
>> Hi Nasser,
>> Thank you for the report.
>> 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?
>> What sort of database do you have? Does it have any conflicted
>> versions in it?
>> 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.
>> Please don't email logfiles directly to this list; you can share them
>> with a service like, or
>> instead.
>> 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.
>> -Joan
>> ----- Original Message -----
>> From: "Nasser Ebrahim" <>
>> To:
>> Sent: Wednesday, 3 May, 2017 1:48:06 PM
>> Subject: Truncated response when POST a _changes query
>> Hello,
>> While doing the Cloudant swift test, we are getting truncated response
>> when POST a _changes  query  to the CouchDB with document ID [
>> <>].
>> We are getting the failure very frequent while doing the test from a
>> swift client on Linux with couchDB 2.0 as server. We compared the TCP
>> stream of the passing and failing case and the request is exactly the
>> same. Hence, we believe there is something going wrong while processing
>> the request on the CouchDB side as we are getting the truncated response.
>> Another interesting observation is that if we introduce a small delay
>> (sleep) before writing the request body on the swift client side, the
>> test is passing (the response from CouchDB is proper). Hence, we think
>> this could be a timing related issue on the CouchDB side.
>> While doing the same Cloudant swift test from Mac OS, we are observing
>> the failure very rarely. We believe it could be the change in timing
>> which hide the issue similar to when we introduce the delay while
>> testing on Linux.
>> The response from the CouchDB has three chunks. The first chunk is a
>> standard text {"results”:[, the second chunk is the actual response and
>> the last chunk is the standard stream terminator sequence. In the
>> failing case, we are getting only the first chunk. Hence, it seems the
>> failure occurred while processing the response on the CouchDB side.
>> We have taken the CouchDB trace and Wireshark trace from the server side
>> and we could confirm that the request is exactly the same between the
>> passing and failing case where as the response is truncated on the
>> CouchDB side during the failure.
>> Please let us know whether you are aware of any such issues on the
>> CouchDB side and what diagnostic documents are required for you to do
>> the analysis.
>> Thank you,
>> Nasser Ebrahim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message