Re: [log4perl-devel] Problems with API config using appender Synchronized

[Mike S. <m...@pe...>]

On Thu, 9 Apr 2009, Jens Berthold wrote:

> 1) The sub Log::Log4perl::Appender::Synchronized->post_init() is not
> called when the appender is created via API.  Is this correct?  My way
> to handle this was to write an own class derived from Synchronized an
> copy the code from post_init() to new().

Hi Jens,

as you've noticed, the internal function create_appender_instance()
performs some magic that makes composite appenders work, but this method
isn't suited in its current form to be used from the outside. I'll dig
into the internals to find a way to fix this.

As it is now, you'd have to do something like

     use Log::Log4perl qw(get_logger :levels);

     my $fileApp = Log::Log4perl::Appender->new(
        'Log::Log4perl::Appender::File',
        name     => 'MyFileApp',
        filename => 'mylog',
        mode     => 'append',
     );
     $fileApp->layout(
        Log::Log4perl::Layout::PatternLayout::Multiline->new(
 	   '%d{yyyy-MM-dd HH:mm:ss} %p [%c] #%P> %m%n')
     );
     $Log::Log4perl::Logger::APPENDER_BY_NAME{"MyFileApp"} = $fileApp;

     my $syncApp = Log::Log4perl::Appender->new(
        'Log::Log4perl::Appender::Synchronized',
        name       => 'MySyncApp',
        appender   => 'MyFileApp',
        key        => 'nem',
     );
     $syncApp->post_init();
     $syncApp->composite(1);
     get_logger("")->add_appender($syncApp);
     get_logger("")->level($DEBUG);
     get_logger("wonk")->debug("waah!");

which is most certainly terrible and, as mentioned above, needs to be 
fixed in one of the upcoming Log4perl releases.

One more thing: Is there a reason why you're using 'syswrite' and the
Synchronized appender in combination? By using 'syswrite', you won't
need the Synchronized appender at all, because the OS will make sure
that messages will be written out entirely without overlap.

> 3) When initialising Log::Log4perl::Appender::Synchronized before
> forking child processes, eventually all existing processes try to remove
> the semaphore.
> I could only solve this with a derived class that stores the process id
> of the parent and only allowed the parent to remove the semaphore.

Hmm, this sounds like a bug, but I'm not sure what your 'existing'
processes are doing in this case -- can you provide some test code?

-- Mike

Mike Schilli
m...@pe...