Waiting on _bulk_get check to replicate with remote database #5501

Closed
JosiahWitt opened this Issue Jul 25, 2016 · 10 comments

Projects

None yet

5 participants

@JosiahWitt

Environment (Node.js/browser/hybrid app/etc.)

Browser (PouchDB 5.4.4)

Browser/platform (Chrome/FF/Safari/Edge/iOS/Android/etc.)

Chrome 51 (Ubuntu & Android), Firefox 47 (Ubuntu), Safari 9 (iOS)

Adapter (IndexedDB/WebSQL/LevelDB/etc.)

IndexedDB, WebSQL

Server (CouchDB/Cloudant/Couchbase/PouchDB Server/etc.)

CouchDB 1.4.0

Please describe your issue. Test cases (e.g. JSBin) are very helpful!

I am developing an application in Angular2 using PouchDB and PouchDB Authentication. I destroy the local database on logout and replicate with the remote database on login.

After the user logs in, during replication, PouchDB attempts to use the _bulk_get API. This results in a series of POSTs to the remote database with _bulk_get?revs=true which all immediately fail with net::ERR_CONNECTION_RESET in Chrome. These continue for 10-70 seconds, during which the user doesn't receive any data from the server. The doBulkGet check function receives an error of:

Object {status: 0, name: "unknown", message: undefined}

After the series of these, PouchDB receives a 400 error from the server.

I modified the library and set supportsBulkGet to false, and the user only had to wait 2-5 seconds for the data on login. While this issue persists, is there a way to manually set _bulk_get support?

If you need any additional information, please let me know. Thank you!

@daleharvey
Member

Hm, I thought we tested against couch 1.4 while developing this, getting an ERR_CONNECTION_RESET is quite strange, are you exposing CouchDB directly or going through a reverse proxy (possibly with SSL involved?).

Either way, sorry there isnt a flag for supportsBulkGet but looks like we should fix the clause @ https://github.com/pouchdb/pouchdb/blob/master/packages/pouchdb-adapter-http/src/index.js#L337 to make sure 0 indicates error (we should probably make it a whitelist)

@daleharvey daleharvey added the bug label Jul 26, 2016
@JosiahWitt

are you exposing CouchDB directly or going through a reverse proxy (possibly with SSL involved?).

I am accessing CouchDB directly through the HTTP API. We haven't enabled SSL yet, as the dev server is on the same network switch as us. Thanks!

@daleharvey
Member

Its very strange for chrome to terminate the connection in that way, the bulk get check should be seeing the 400, the fix for this will be fairly safe so I dont think it needs to block it landing, but it may be worth looking into

@nolanlawson
Member

We've only tested against CouchDB 1.6.x for a long time, and I know for a fact there are test suite failures in 1.5. If there are bugs in 1.4 that doesn't really surprise me.

@JosiahWitt Would be interested to know if an upgrade to CouchDB 1.6.1 solves this.

@nolanlawson
Member

Actually wait, is this the same issue as nolanlawson/pouchdb-authentication#111 ? Chrome changed something in v52 and apparently it broke pouchdb-authentication.

@JosiahWitt

Would be interested to know if an upgrade to CouchDB 1.6.1 solves this.

@nolanlawson We can try an upgrade to CouchDB 1.6.1, however it might be a few days.

is this the same issue as nolanlawson/pouchdb-authentication#111 ?

I had this issue before I updated to Chrome v52 as well as in Firefox. I can confirm, however, that I also have the referenced issue with Chrome v52 and pouchdb-authentication. Chrome v52 does appear to have broken pouchdb-authentication.

Thanks!

@tnightingale

I am running CouchDB 1.6.1 and PouchDB 5.4.5 and during replication I occasionally get net::ERR_CONNECTION_RESET in Chrome 52. When this occurs PouchDB's info log message: "The above 400 is totally normal. PouchDB is just detecting if the remote supports the _bulk_get API." does not show and the replication doesn't complete.

It seems to happen intermittently and I can't determine what specific conditions cause it but when it happens, it happens consistently for a few attempts before working again.

@bfredo123

Hi,

Can you please help me? I am having the same issues, how could I work this around?
Chrome 54
PouchDB 6.0.7
CouchDB 1.6.1

Below are the Chrome logs after the attempt to sync from PouchDB (192.168.0.5 is the server hosting CouchDB, but also the webserver for Ionic/PouchDB):

Navigated to http://192.168.0.5:8100/
GET http://192.168.0.5:5984/mydb/_local/JHHrt.m0cfB_HNqCTpEHWg%3D%3D? 404 (Object Not Found)
Uncaught TypeError: Cannot read property 'rows' of undefined(…)
GET http://192.168.0.5:5984/mydb/_local/JHHrt.m0cfB_HNqCTpEHWg%3D%3D? 404 (Object Not Found)
The above 404 is totally normal. PouchDB is just checking if a remote checkpoint exists.
GET http://192.168.0.5:5984/mydb/_local/ujZLz0FusKdCum2I.Z9ZkA%3D%3D? 404 (Object Not Found)
The above 404 is totally normal. PouchDB is just checking if a remote checkpoint exists.
POST http://192.168.0.5:5984/mydb/_bulk_get?revs=true net::ERR_CONNECTION_RESET
POST http://192.168.0.5:5984/mydb/_bulk_get?revs=true net::ERR_CONNECTION_RESET
Uncaught (in promise) Error: Uncaught, unspecified "error" event. ([object Object])(…)

@nolanlawson
Member

This bug does not seem to have a test case; a test case would be appreciated so that we can reproduce it.

@willholley willholley added a commit that referenced this issue Dec 20, 2016
@willholley willholley (#5501) - fall back from bulk_get on any error
Multiple users have reported connectivity issues during our test
for the _bulk_get endpoint. Rather than raise a user error in these
situations, fall back to individual document GETs - any real
connection issues will get raised at that point.

Fixes #5810, #5501
e1530ce
@willholley willholley added a commit that referenced this issue Dec 20, 2016
@willholley willholley (#5501) - fall back from bulk_get on any error
Multiple users have reported connectivity issues during our test
for the _bulk_get endpoint. Rather than raise a user error in these
situations, fall back to individual document GETs - any real
connection issues will get raised at that point.

Fixes #5810, #5501
40e0751
@nolanlawson nolanlawson added a commit that referenced this issue Dec 21, 2016
@willholley @nolanlawson willholley + nolanlawson (#5501) - fall back from bulk_get on any error
Multiple users have reported connectivity issues during our test
for the _bulk_get endpoint. Rather than raise a user error in these
situations, fall back to individual document GETs - any real
connection issues will get raised at that point.

Fixes #5810, #5501
cb020e3
@nolanlawson
Member

fixed in #6036

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment