in reply to [log4perl] log level vs. threads

Different threads will have separate private copies of the Log::Log4perldata structures, so any changes you make in one thread will not affect another.

I can think of three solutions to your problem.

  1. Make the Log4perl data structure shared between threads. This might not work if Log4perl is not thread safe.
  2. Find a way of signalling between threads via another shared variable, sockets, signals etc, so they all change their log level at once.
  3. Make changes to the log4perl config file, and take advantage of the fact that log4perl can watch for changes and automatically reload the file,

Of the three options, I think the third is probably the most reliable and safest in the long term.

I would also ask why you are changing the log level at runtime?

If it is as a response to an exceptional situation, then it would probably be better to log at a higher level to begin with, and adjust the retention of those detailed log files in response to a problem.

Also it is worth noting that you can have different log4perl configurations for different classes within you perl program, so that would be another way of having more detailed logging for an area that deserves more logging.

Replies are listed 'Best First'.
Re^2: [log4perl] log level vs. threads
by menth0l (Monk) on Aug 31, 2011 at 11:11 UTC
    Thanks for your suggestions. I want change log levels dynamically via xmlrpc to view detailed output when my app behaves in unexpected way. Now, i think i'll see what signals can offer me...
      As chrestomanci has pointed out, Log4Perl already has the functionality built in to determine if the configuration file has changed between logging calls.

      So, just adjust the default log-level and rewrite the file. The change will flow naturally from there. No need to be mucking with the additional complication of cross-thread communications....

      I Go Back to Sleep, Now.


        The solution of watching a log file doesn't work of course if you choose to write your config options in the code versus a configuration file. What I found to work is to explicitly call the init() function to re-initialize after making the changes you desire to the config options. The catch is that this must be done within each thread. I wrote a little about this here: