Feature #3553
open
Logging facility: bounded record queue
Added by Alex Afanasyev over 8 years ago.
Updated over 4 years ago.
Description
The current implementation hardcodes the default unbounded_fifo_queue for the asynchronous sink frontend of Boost.Log.
Boost.Log allows some compile-time customization via template arguments.
This task is to allow setting some upper bound on the logging queue length and test operations under different load conditions.
- Blocked by Task #2513: Optimize multi-threaded logging using lock-free queue and separate thread added
- Subject changed from Use bounded logging queue for Boost.Log to Use bounded record queue for Boost.Log
- Category set to Core
Which overflow strategy should be used? drop or block?
I would drop. Logging is, in my opinion, secondary to the actual forwarding function.
I agree in principle, but there's a not-so-small problem with Boost.Log drop_on_overflow implementation: log records are dropped silently, which could be rather inconvenient if you're trying to debug something...
Can be there a config-level option? Or, we can have different behavior for release and debug versions. For releases, we should definitely use drop_on_overflow. Ideally, there should be some indication that the log was cut...
The behavior is decided by a template argument, so whatever we do, it must be a compile-time choice.
Ideally, there should be some indication that the log was cut...
100% agree. Unfortunately it doesn't currently seem possible with Boost.Log.
- Tracker changed from Task to Feature
- Project changed from NFD to ndn-cxx
- Subject changed from Use bounded record queue for Boost.Log to Support bounded record queue for Boost.Log
- Description updated (diff)
- Category changed from Core to Utils
Moving to ndn-cxx project since NFD logging is being reimplemented on top of ndn-cxx logging.
- Subject changed from Support bounded record queue for Boost.Log to Logging facility: bounded record queue
- Description updated (diff)
Also available in: Atom
PDF
Updated by 
Updated by