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.
1 file changed
tree: be1492428b95279e747ebec38a3ca51ff29bd880
  1. .gitignore
  2. LICENSE
  3. README.md
  4. priv/
  5. src/
README.md

global_changes

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

Captured Metrics

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.

Important Configs

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.