Project

General

Profile

Bug #3782

Logging facility conflicts with app using Boost.Log

Added by Junxiao Shi over 3 years ago. Updated 11 months ago.

Status:
Code review
Priority:
Normal
Category:
Utils
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
6.00 h

Description

As discovered in #3761, when two sinks are added to Boost.Log, messages will appear twice or scrambled on OS X platform.

NFD avoids the problem by letting ndn-cxx initialize Boost.Log.
However, if an application directly uses Boost.Log and adds its own sink, it would still conflict with ndn-cxx logging facility and cause messages to appear twice.


Related issues

Blocked by NFD - Bug #3761: Duplicate/scrambled characters in log messageClosedAlex Afanasyev09/01/2016

Actions
#1

Updated by Junxiao Shi over 3 years ago

  • Blocked by Bug #3761: Duplicate/scrambled characters in log message added
#2

Updated by Alex Afanasyev 11 months ago

I would like to close this old issue. It is a known issue, but I don't think there is any solution to this.

If ndn-cxx based app wants to do its own init of the sink, it needs to set a "null" destination before doing anything else. I guess, the only we can do here is to simply provide a simpler way to set such a "null" sink.

If app is not ndn-cxx based, it doesn't have the issue.

The only real problem would be for the app that uses the library that uses ndn-cxx (i.e., the app doesn't directly interact with ndn-cxx). Don't think this would be easily solvable and even in that case app still kind of aware of ndn-cxx existence and can do smarter things with the log init.

#3

Updated by Davide Pesavento 11 months ago

Fine with me.

#4

Updated by Junxiao Shi 11 months ago

If ndn-cxx based app wants to do its own init of the sink, it needs to set a "null" destination before doing anything else.

Please give an example of how to do this, either in the codebase as a test case or example, or on this Redmine page. Then the issue may close.

#5

Updated by Alex Afanasyev 11 months ago

  • Status changed from New to Code review

https://gerrit.named-data.net/#/c/ndn-cxx/+/5520/

Example of this would be to call Logging::replaceLogger(nullptr);. However, as I just described in gerrit, Boost.Log has some "interesting" default sink that kicks in when all custom sinks are removed. I'm observing output like

[2019-07-13 12:26:17.830211] [0x000000011d8055c0] [info]    fatal1

I think we can live with this, as it still addresses the problem of this issue and allows effective replacement of the log sink to anything that application desires.

#6

Updated by Alex Afanasyev 11 months ago

  • Assignee set to Alex Afanasyev
  • Target version set to v0.8

In the latest patchset, the API for this changed (=simplified) to just Logging::setLogger(nullptr);

Also available in: Atom PDF