Add sink after logger has been created

[persona94]

Use case : create a logger with 1 kind of sink, but add another sink later.

Let's say I create a console sink at the program start-up. Then later on in program execution I decide that I need a file logger as well. I'm finding that calling create_or_get_logger a second time doesn't add the new sink

auto quill_sink = quill::Frontend::create_or_get_sink<quill::ConsoleSink>("console_logger");
  logger =
    quill::Frontend::create_or_get_logger("root", {std::move(quill_sink)});


if(need_file_also) { 
  auto rotating_file_sink = quill::Frontend::create_or_get_sink<quill::RotatingFileSink>(
  "/tmp/rotating_file.log",
  []()
  {
    // See RotatingFileSinkConfig for more options
    quill::RotatingFileSinkConfig cfg;
    cfg.set_open_mode('w');
    cfg.set_filename_append_option(quill::FilenameAppendOption::StartDateTime),
    cfg.set_rotation_max_file_size(1024);
    return cfg;
  }());

  logger =
    quill::Frontend::create_or_get_logger("root", rotating_file_sink);
}


LOG_INFO("This is a msg");

When I run this I only get logs on console. It creates a log file, but no logs are written to it. If I pass down both sinks for the same create_or_get_sink call I see both logs. Am I not calling the functions correctly?

[odygrd]

Hey, the API doesn't allow that because it wouldn't be safe. Allowing this would require the backend worker thread to either take a lock or a thread-safe check for updated sinks before forwarding each log message, which would introduce performance overhead. Once a Logger is created, new sinks cannot be added.

quill::Frontend::create_or_get_logger ensures that a logger with a given logger_name is created only once. If the logger already exists, the existing instance is returned instead of creating a new one—this is why you see only a single sink.

You have a few options:

1. Use a different logger name and simply switch to using the latest created logger (simplest and recommended)

   auto logger_1 = quill::Frontend::create_or_get_logger("logger_1", console_sink);
   auto logger_2 = quill::Frontend::create_or_get_logger("logger_2", {console_sink, file_sink});

2. Create the logger with both sinks from the start, but disable logging on the file sink initially - also simple - 2nd recommendation

   #include "quill/Backend.h"
   #include "quill/Frontend.h"
   #include "quill/LogMacros.h"
   #include "quill/Logger.h"
   #include "quill/sinks/ConsoleSink.h"
   #include "quill/sinks/FileSink.h"
   
   #include <string>
   
   // Stored logger pointer
   quill::Logger* g_logger{nullptr};
   
   int main()
   {
     quill::BackendOptions backend_options;
     quill::Backend::start(backend_options);
   
     auto console_sink = quill::Frontend::create_or_get_sink<quill::ConsoleSink>("sink_id_1");
     auto file_sink = quill::Frontend::create_or_get_sink<quill::FileSink>("example_file_logging.log");
     file_sink->set_log_level_filter(quill::LogLevel::None);
   
     // Store created logger
     std::string const logger_name{"root"};
     g_logger = quill::Frontend::create_or_get_logger(logger_name, { std::move(console_sink), std::move(file_sink) });
   
     LOG_INFO(g_logger, "A {} message with number {}", "log", 123);
   
     // flush any remaining logs to avoid race condition before changing the filter
     g_logger->flush_log();
   
     // Get the file sink and set_log_level_filter - thread safe to be called from any thread - enables file logging
     quill::Frontend::get_sink("example_file_logging.log")->set_log_level_filter(quill::LogLevel::TraceL3);
   
     LOG_INFO(g_logger, "A second {} message with number {}", 456, "log");
   }

3. Remove and recreate the logger with updated sinks

   If you choose this approach, make sure to update any stored references to the old logger, as it becomes invalid after removal. Also no other thread should try to log using the logger* after calling remove_logger and before recreating it.

   #include "quill/Backend.h"
   #include "quill/Frontend.h"
   #include "quill/LogMacros.h"
   #include "quill/Logger.h"
   #include "quill/sinks/ConsoleSink.h"
   #include "quill/sinks/FileSink.h"
   
   #include <string>
   
   // Stored logger pointer
   quill::Logger* g_logger{nullptr};
   
   int main()
   {
     quill::BackendOptions backend_options;
     quill::Backend::start(backend_options);
   
     auto console_sink = quill::Frontend::create_or_get_sink<quill::ConsoleSink>("sink_id_1");
   
     // Store created logger
     std::string const logger_name{"root"};
     g_logger = quill::Frontend::create_or_get_logger(logger_name, std::move(console_sink));
   
     LOG_INFO(g_logger, "A {} message with number {}", "log", 123);
   
     // Remove the logger
     // total_loggers can help you check the logger is actually removed, as long as you are not creating/removing other loggers
     // from different threads simultaneously
     g_logger->flush_log();
     size_t const total_loggers = quill::Frontend::get_number_of_loggers();
     quill::Frontend::remove_logger(g_logger);
   
     // remove_logger is async, after this call logger is invalidated but still exists,
     // we want to wait until it is actually removed by the Backend
     // quill::Frontend::get_number_of_loggers() is the only function that will also take invalidated loggers into account
     while (quill::Frontend::get_number_of_loggers() != (total_loggers - 1))
     {
       // wait
     }
   
     // Now the logger is removed, we can re-create
     auto existing_console_sink = quill::Frontend::create_or_get_sink<quill::ConsoleSink>("sink_id_1");
     auto file_sink = quill::Frontend::create_or_get_sink<quill::FileSink>("example_file_logging.log");
   
     // Make sure you also update all references to the previous logger* (e.g. if stored as class member) as the previous
     // is now invalid after removal
     g_logger = quill::Frontend::create_or_get_logger(logger_name, { std::move(existing_console_sink), std::move(file_sink)});
   
     LOG_INFO(g_logger, "A second {} message with number {}", 456, "log");
   }

Let me know if you need further help!

[persona94]

All fantastic options, thank you! I was initially considering option #3 but #1 is actually quite clean so I'll do that instead.