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 <[email protected]> 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" <[email protected]>
To: [email protected]
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" <[email protected]>
To: [email protected]
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 <[email protected]> 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" <[email protected]>
To: [email protected]
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
