Closed dynamite-ready closed 7 years ago
Could Hackney be responsible for the early timeout?
do you actually checked the url over your couchdb nde? On Mon, 21 Mar 2016 at 15:56, dynamite-ready notifications@github.com wrote:
Could Hackney be responsible for the early timeout?
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/benoitc/couchbeam/issues/141#issuecomment-199325514
I did.
Using this URL - localhost:5984/db1/_changes?feed=longpoll&timeout=30000&since=now&filter=foo/bar - from Chrome, takes 30000ms to timeout as expected.
But setting either the timeout value or the heartbeat value above 5000ms does not work.
If, however, I set - {heartbeat: 4000} - (to a value less than 5000), I can fool the couchbeam client and keep the changes feed open.
It's a workaround, but it's a bad hack.
@dynamite-ready did you tested it with curl ? Actually this is more likely how works couchdb. heartbeat should be less than the timeout value. Did I miss anything?
did you tested it with curl ? Actually this is more likely how works couchdb. heartbeat should be less than the timeout value. Did I miss anything?
Yes. Basically, and {timeout, 10000} won't work. The request will still end after 5000ms. What I would like to do, is set the timeout to {timeout: 60000}, and set the heartbeat to {heartbeat: 30000}
Testing from both Chrome and CURL is fine. The request also makes it to the Couch log file. But the request always times out after 5 seconds from couchbeam_changes.
Thank you for looking into this.
Any update on this issue?
I still suspect it's Hackney that times out early, breaking my attempt to override the CouchDB timeout value.
Looking at the default timeout for receiving a connection in Hackney - https://github.com/benoitc/hackney/search?utf8=%E2%9C%93&q=5000 - Appears to match up with my suspicion.
I'm trying to use the Couchbeam
couchbeam_changes:follow_once
function with the following parameters:There's no compilation error, but the call appears to timeout after just a few seconds, yielding -
{error, {closed, timeout}}
. Not the 60000ms I've set thetimeout
orheartbeat
parameters for. Is there a bug in the library here?Googling around, the closest issue I can find to mine, is this one: https://github.com/benoitc/couchbeam/issues/132
Similar issue, different method.
For the record, my Couch instance is at v1.6.1
The details here, ad verbatim, can also be found on Stackoverflow: http://stackoverflow.com/questions/36104439/couchbeam-couchbeam-changesfollow-once-times-out-prematurely
EDIT - Looking at the CouchDB log file, I've noticed how
?reconnect_after=false&...
is in the list of query string parameters, but the parameter doesn't appear in the CouchDB changes documentation - http://docs.couchdb.org/en/stable/api/database/changes.html - Might that be part of the issue?