| commit | 5c0b30e2e63a22d100bdc4bf532c1df73fbb9b59 | [log] [tgz] |
|---|---|---|
| author | Paul J. Davis <paul.joseph.davis@gmail.com> | Fri Aug 22 05:05:59 2014 -0500 |
| committer | Paul J. Davis <paul.joseph.davis@gmail.com> | Fri Aug 22 05:05:59 2014 -0500 |
| tree | be1492428b95279e747ebec38a3ca51ff29bd880 | |
| parent | 727868f16487e40c5b2281939cbe7beb7d764c1d [diff] |
Fix race condition by relying on admin only Since we no longer have to worry about filtering for users we can let fabric take care of the underlying limit implementation for now. Without this there's a race condition where fabric will wait for Timeout seconds before actually stopping. Any activity in that window will be sent through the callback and forwarded on to clients. There's probably a way to fix that but my brain isn't working so well right now.
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.