in reply to Re: log level in modules
in thread log level in modules

OK, some clarification:

If we ignore the changing of log levels, everything works as expected.

And here is the program flow:

program start -> initialize logger <<Log::Log4perl::init("log.properti +es")>> -> get the logger <<my $logger = get_logger()>> -> use fork() +to create threads -> wait for threads to die
child start -> change NDC <<Log::Log4perl::NDC->push($NDC)>> -> do the +ir thing, including using customer modules

The modules use my $logger = get_logger() to get the logger. Messages from the modules use the correct NDC as configured for each thread.

Let's say my module is as simple as:

use Log::Log4perl (get_logger); my $logger = get_logger(); sub sayHello { $logger->info("Hello world!"); }

Doesn't that mean that every time a thread executes that sayHello sub, the module gets the logger then logs a message?

If so, why doesn't it get the new logging level? If I start with level WARN specified in my config file, I don't expect to see the message in my logs. That part works just fine. If I then use the signal to lower the level to INFO, I would expect to see the message start appearing in the log. It doesn't.

Replies are listed 'Best First'.
Re^3: log level in modules
by ikegami (Patriarch) on Aug 21, 2009 at 17:55 UTC

    use fork() to create threads

    fork doesn't create threads*, it creates new processes which are copies of the parent. You're only sending the signal the parent process, so nothing changes the copies of the logger objects found in the child processes.

    Even if you did create threads, Perl gives each thread a copy of every Perl variable except for variables that had been shared explicitly. You didn't create a shared variable that holds a logger object, and I doubt that the logger does this for you.

    * — Except in Windows. fork is emulated using threads in Windows.

      My apologies if "thread" was the incorrect term. Yes, I'm aware of what happens when fork() is used. Part of the signal handler is to pass on the signal to all the children (copies).

      As stated in the original post, there is no problem with changing the logging level for the parent or children (copies). The change in logging level is reflected in all these entities. It's the modules that don't want to cooperate.

        So why do you think it has anything to do with forking? The problem occurs entirely inside each process from what you now say.

        So why do you think it has anything to do with signals?

        So far, all you've told us is

        Changing the log level of $logger doesn't affect the logging level in the logger returned by get_logger

        And I'm here asking "And....?"

        It seems your problem could be recreated in 5 lines. Why didn't you post these?