Is your feature request related to a problem? Please describe.
The current implementation of the Couch DB changes feed subscribes to all changes. In a heavily used database it can take several minutes to receive all changes from the server.
The time window that the _changes feed looks back over is undefined according to the CouchDB docs, but based on real-world observation Open MCT is receiving hundreds of thousands of "recent" updates on subscription to the feed.
Open MCT subscribes on first load of the application, but also resubscribes if the feed is lost for any reason. Again, in observing real-world usage we do occasionally lose the feed, which in itself is not a problem as we just resubscribe. The problem is that every subscription requires several minutes to receive and process Couch DB changes. Receiving this fire-hose of updates actually serves to block useful object updates, such as new notebook entries, from being received by the user.
I think our original implementation was based on the reasonable assumption that the Couch DB changes feed only provided changes that occur after the subscription is established. In actual fact on subscription Couch DB provides the last N changes, where N is undefined (even in the docs).
Describe the solution you'd like
The _changes endpoint supports a since parameter, which supports a string literal value of now. We should modify our Couch DB Changes Feed to add this parameter on subscription.
Is your feature request related to a problem? Please describe.
The current implementation of the Couch DB changes feed subscribes to all changes. In a heavily used database it can take several minutes to receive all changes from the server.
The time window that the _changes feed looks back over is undefined according to the CouchDB docs, but based on real-world observation Open MCT is receiving hundreds of thousands of "recent" updates on subscription to the feed.
Open MCT subscribes on first load of the application, but also resubscribes if the feed is lost for any reason. Again, in observing real-world usage we do occasionally lose the feed, which in itself is not a problem as we just resubscribe. The problem is that every subscription requires several minutes to receive and process Couch DB changes. Receiving this fire-hose of updates actually serves to block useful object updates, such as new notebook entries, from being received by the user.
I think our original implementation was based on the reasonable assumption that the Couch DB changes feed only provided changes that occur after the subscription is established. In actual fact on subscription Couch DB provides the last N changes, where N is undefined (even in the docs).
Describe the solution you'd like
The _changes endpoint supports a
sinceparameter, which supports a string literal value ofnow. We should modify our Couch DB Changes Feed to add this parameter on subscription.