1. 19 Mar, 2013 4 commits
  2. 15 Mar, 2013 5 commits
  3. 14 Mar, 2013 8 commits
  4. 13 Mar, 2013 2 commits
  5. 12 Mar, 2013 2 commits
  6. 11 Mar, 2013 3 commits
    • Andrew Thompson's avatar
      Merge pull request #116 from basho/adt-msg-drop · 135bbddb
      Andrew Thompson authored
      Implement configurable error_logger msg drop threshold
      135bbddb
    • Scott Lystig Fritchie's avatar
      A few small things: · a702bf10
      Scott Lystig Fritchie authored
      1. Add set_high_water/1 to adjust the high water mark after startup
      2. Add test func t0/0 to demo (interactively only, sorry) that the
         limiting is working as we expect).
      3. Remove a couple of comments.
      a702bf10
    • Andrew Thompson's avatar
      Implement configurable error_logger msg drop threshold · ef691d89
      Andrew Thompson authored
      Implement a new config option error_logger_hwm, which is a number
      representing how many messages per second we should log from the
      error_logger. If that threshold is exceeded, messages will be discarded
      for the remainder of that second.
      
      This is only effective if lager itself can process the messages fast
      enough to satisfy the threshold. If your threshold is 1000 and lager
      itself is only writing 100 messages a second (because error messages are
      causing fsyncs or whatever) you'll never exceed the threshold and drops
      will never happen. Thus care needs to be taken when selecting this
      feature.
      
      Setting it low is not as bad as it might seem, because when using lager,
      hopefully error_logger messages are unusual. In my testing, 50/second
      with the default config seemed reasonable (which has 2 file backends
      installed, both of which fsync on messages at error or above).
      ef691d89
  7. 08 Mar, 2013 1 commit
    • Andrew Thompson's avatar
      Switch between gen_event notify/sync_notify based on message queue length · cf89804c
      Andrew Thompson authored
      In normal operation, there's no need for log messages to be synchronous.
      Its slower and introduces a global serialization point in the
      application.
      
      However, when in an overload condition, synchronous logging is good
      because it limits each process to at most 1 log message in flight.
      
      So, this change allows the gen_event at the core of lager to switch
      modes depending on the size of the gen_event's mailbox. It should
      provide better performance in the case of normal load, but it will also
      prevent unbounded mailbox growth if an overload occurs.
      
      The threshold at which the switch between async and sync is done is
      configured via the 'async_threshold' app env var.
      cf89804c
  8. 07 Mar, 2013 5 commits
  9. 05 Mar, 2013 2 commits
  10. 02 Mar, 2013 2 commits
  11. 27 Feb, 2013 4 commits
  12. 26 Feb, 2013 2 commits