Project

General

Profile

Actions
Copy link

Feature #3553

open

Logging facility: bounded record queue

Added by Alex Afanasyev almost 9 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Utils
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Tags:
logging

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.

Related issues 1 (0 open — 1 closed)

Blocked by NFD - Task #2513: Optimize multi-threaded logging using lock-free queue and separate threadClosedYumin Xia

Actions
Actions
Copy link
 #1

Updated by Alex Afanasyev almost 9 years ago

  • Blocked by Task #2513: Optimize multi-threaded logging using lock-free queue and separate thread added
Actions
Copy link
 #2

Updated by Davide Pesavento almost 9 years ago

  • 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?

Actions
Copy link
 #3

Updated by Alex Afanasyev almost 9 years ago

I would drop. Logging is, in my opinion, secondary to the actual forwarding function.

Actions
Copy link
 #4

Updated by Davide Pesavento almost 9 years ago

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...

Actions
Copy link
 #5

Updated by Alex Afanasyev almost 9 years ago

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...

Actions
Copy link
 #6

Updated by Davide Pesavento almost 9 years ago

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.

Actions
Copy link
 #7

Updated by Davide Pesavento over 6 years ago

  • 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.

Actions
Copy link
 #8

Updated by Davide Pesavento over 6 years ago

  • Subject changed from Support bounded record queue for Boost.Log to Logging facility: bounded record queue
  • Description updated (diff)
Actions
Copy link
 #9

Updated by Davide Pesavento over 4 years ago

  • Tags set to logging
Actions
Copy link

Also available in: Atom PDF