You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A good point was raised that we don't do any internal buffering of logs in handle scribe. We may want to provide the user with controls such as how many (if any) messages to buffer, when to fsync, etc. Our elasticsearch scribe actually does some buffering with a bounded queue but this is just a memory usage tactic. Scribes still eagerly send every message as soon as they get it. There may be a heuristic there where its preferable to wait and use the bulk indexing API in elasticsearch.
The text was updated successfully, but these errors were encountered:
Yeah, katip-elasticsearch sets a good precedence of this: gathers all configuration into a type, exports only the type and lenses to its fields and a default constructor for maximum backwards compatibility when new fields are added. The next time we have to add configuration to the handle scribe (or add a new scribe) we should pull the band-aid off and gather all of its configuration arguments into a type.
A good point was raised that we don't do any internal buffering of logs in handle scribe. We may want to provide the user with controls such as how many (if any) messages to buffer, when to fsync, etc. Our elasticsearch scribe actually does some buffering with a bounded queue but this is just a memory usage tactic. Scribes still eagerly send every message as soon as they get it. There may be a heuristic there where its preferable to wait and use the bulk indexing API in elasticsearch.
The text was updated successfully, but these errors were encountered: