benoitc / couchbeam

Apache CouchDB client in Erlang
Other
242 stars 113 forks source link

Couchbeam - couchbeam_changes:follow_once times out prematurely #141

Closed dynamite-ready closed 7 years ago

dynamite-ready commented 8 years ago

I'm trying to use the Couchbeam couchbeam_changes:follow_oncefunction with the following parameters:

    {_, yield} = couchbeam_changes:follow_once(
       database,
       [
           longpoll,
           {since, seq},
           {heartbeat, 60000},
           {filter, "_view"},
           {view, "match/date"}
       ]
    )

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 the timeout or heartbeat 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?

dynamite-ready commented 8 years ago

Could Hackney be responsible for the early timeout?

benoitc commented 8 years ago

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

dynamite-ready commented 8 years ago

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.

benoitc commented 8 years ago

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

dynamite-ready commented 8 years ago

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.

dynamite-ready commented 8 years ago

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.