couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: Truncated response when POST a _changes query
Date Tue, 23 May 2017 08:04:07 GMT
Nasser,

It looks like you are trying to connect only through the "back side"
port at port 5988. You should only use this port where instructed
in the documentation - specifically, for setting up clusters.

Please try your experiment again through the port you've assigned
to the chttpd application - in your logfiles, port 5986, and let us
know if the problem persists.

Best regards,
Joan

----- Original Message -----
From: "Joan Touzet" <wohali@apache.org>
To: dev@couchdb.apache.org
Sent: Thursday, 18 May, 2017 2:05:35 PM
Subject: Re: Truncated response when POST a _changes query

Hi Nasser,

I'm afraid not yet. Please remember that CouchDB is a volunteer-run
project, and we wear many hats. There are options for commercial
support of CouchDB if you need urgent support.

Best regards,
Joan

----- Original Message -----
From: "Nasser Ebrahim" <enasser@linux.vnet.ibm.com>
To: dev@couchdb.apache.org
Sent: Thursday, May 18, 2017 6:04:46 AM
Subject: Re: Truncated response when POST a _changes query

Hi Joan and Robert,

Did you get a chance to look into the logs? Please let us know if you 
need any further information or diagnostic data to progress this issue.

Thank you,

Nasser Ebrahim


On 5/9/17 2:42 PM, Nasser Ebrahim wrote:
> 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 0.0.0.0 to let CouchDB listen any 
> available IP address
>
>     * change port from 5984 to 5988 as 5984 is used by another 
> application in that machine.
>
> [log]
> level = debug
>
> [httpd]
> port = 5988
> bind_address = 0.0.0.0
>
>  - 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 
> https://drive.google.com/drive/folders/0BxTjd-f_AKG5RlpUVHl5RkRiUGs
>
> 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 <wohali@apache.org> 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 gist.github.com, pastebin.com or paste.apache.org
>>> 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" <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
>>>
>>> Hello,
>>> While doing the Cloudant swift test, we are getting truncated response
>>> when POST a _changes  query  to the CouchDB with document ID [
>>> <http://docs.couchdb.org/en/2.0.0/api/database/changes.html>http://docs.couchdb.org/en/2.0.0/api/database/changes.html].

>>>
>>> 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
>
>


Mime
View raw message