| commit | c0f03829df9444c72e3b5c73143d2ada3f3ca0e2 | [log] [tgz] |
|---|---|---|
| author | Benjamin Bastian <benjamin.bastian@gmail.com> | Fri Dec 13 14:31:30 2013 -0800 |
| committer | Robert Newson <rnewson@apache.org> | Thu Aug 07 17:00:36 2014 +0100 |
| tree | 40df2945598614c419b045bed1410c581fc24790 | |
| parent | 129b7c17e12752508004b3af4b548e48f981bd2d [diff] |
Make changes_callback end request when limit=1 Prior to this commit, the limit was hit when limit=0 by the first changes_callback function clause. This makes maybe_finish end the request when limit=1, so that it doesn't have to wait for another change to end the request. BugzID: 26166
This app supplies the functionality for the /_db_updates endpoint.
When a database is created, deleted, or updated, a corresponding event will be persisted to disk (Note: This was designed without the guarantee that a DB event will be persisted or ever occur in the _db_updates feed. It probably will, but it isn't guaranteed). Users can subscribe to a _changes-like feed of these database events by querying the _db_updates endpoint.
When an admin user queries the /_db_updates endpoint, they will see the account name associated with the DB update as well as update
1: global_changes, db_writes: The number of doc updates caused by global_changes.
2: global_changes, server_pending_updates: The number of documents aggregated into the pending write batch.
3: global_changes, listener_pending_updates: The number of documents aggregated into the pending event batch.
4: global_changes, event_doc_conflict: The number of rev tree branches in event docs encountered by global_changes. Should never happen.
5: global_changes, rpcs: The number of non-fabric RPCs caused by global_changes.
1: global_changes, max_event_delay: (integer, milliseconds) The total timed added before an event is forwarded to the writer.
2: global_changes, max_write_delay: (integer, milliseconds) The time added before an event is sent to disk.
3: global_changes, update_db: (true/false) A flag setting whether to update the global_changes database. If false, changes will be lost and there will be no performance impact of global_changes on the cluster.