Re: Running under mod_perl (was Re: [log4perl-devel] Can't call method "PRINT" on an undefined value)

[Mike S. <msc...@ao...>]

Kevin Goess wrote on 1/13/2004, 8:27 AM:

 > | BTW, why won't this code work in a multi-threaded environment?

Looks like I was overzealous on this one ... generally speaking, having 
unsynchronized globals in multi-threaded code introduces race 
conditions. However, perl's 5.6+ threading model doesn't share variables 
between threads by default, so that's not an issue. And in the special 
case of the code I posted, it would probably even be ok if variables 
were shared, because worst case you would initialize L4p twice, which 
isn't the end of the world.

One thing I wanted to add for mod_perl-like multi-process environments, 
though: No matter if you use a startup handler to init() L4p or use the 
init_once() strategy (just added it to 0.42), you're very likely to have 
unsynchronized writes to logfiles.

If L4p is configured with a log file appender, and it is initialized via 
the Apache startup handler, the file handle created initially will be 
shared among all Apache processes. Similarly, with the init_once() 
approach: although every process has a separate L4p configuration, 
processes are gonna share the appender file *names* instead, effectively 
opening several different file handles on the same file.

Now, having several appenders using the same file handle or having 
several appenders logging to the same file unsynchronized, this might 
result in overlapping messages. Sometimes, this is acceptable. If it's 
not, here's two strategies:

* Use Log4perl's Synchronized appender to connect to your file 
appenders. Here's the writeup:

http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#23804

* Use a different logfile for every process like in

     #log4perl.conf
     ...
     log4perl.appender.A1.filename = sub { "mylog.$$.log" }

Hope that helps ...

-- 
-- Mike
Mike Schilli
m...@pe...