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" <woh...@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" <enas...@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 <woh...@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" <enas...@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 > >
