couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nasser Ebrahim <enas...@linux.vnet.ibm.com>
Subject Re: Truncated response when POST a _changes query
Date Tue, 06 Jun 2017 08:09:38 GMT
Thank you Joan and Robert for your excellent input. We have applied your 
recommendation and it has resolved the issue.

Regards,

Nasser Ebrahim


On 5/23/17 11:49 PM, Robert Samuel Newson wrote:
> hm, this is a pickle.
>
> The out of the box settings are;
>
> [chttpd]
> port = 5984
>
> [httpd]
> port = 5986
>
> You should always be talking to the chttpd port.
>
> The only thing that should be listening on port 5984 is couchdb itself, so perhaps you
have two installations on the same machine?
>
> In any case, the change you should have made was;
>
> [chttpd]
> port = 5988
>
> couchdb doesn't care which port you use but it matters enormously that you are coming
into the clustered port (the 'c' in 'chttpd' means 'clustered').
>
> B.
>
>
>
>> On 23 May 2017, at 09:04, Joan Touzet <wohali@apache.org> wrote:
>>
>> 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