Re: [log4perl-devel] Log4perl and catching unhandle exceptions but not using 'easy' mode
Richard Burton richard-at-atomwide.com |log4perl_sourceforge| wrote:
Hi all
I am trying to capture unhandled exceptions that are sent to STDERR,
e.g. for example the following could would give such an error
[snip]
I can catch this using stealth as loggers outlined in
http://search.cpan.org/~mschilli/Log-Log4perl/lib/Log/Log4perl/FAQ.pm#So
me_module_prints_messages_to_STDERR._How_can_I_funnel_them_to_Log::Log4p
erl?
but the example assumes you are using the easy configuration method.
The question I have is can I do a similar thing but use an external
configuration file for log4perl? I have tried but failed so would
appreciate any guidance?
Here's what I did:
1. Make a file trapper.pl. It's basically the same as the example,
except the Log4perl init, which uses a config file (in this case, with a
SIGHUP to re-read it):
package Trapper;
use Log::Log4perl qw(get_logger :levels);
Log::Log4perl-init_and_watch(../log4perl.conf,'HUP');
my $logger = get_logger(program.category);
sub TIEHANDLE {
... [etc]
2. In my perl program:
require trapper.pl;
tie (*STDERR, 'Trapper');
HTH,
Rob
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] subclassed DBI (DBI_Buffer) does not release dbh filehandles on reinit
Mike Schilli m-at-perlmeister.com |log4perl_sourceforge| wrote:
On Tue, 24 Feb 2009, Robert Jacobson wrote:
Those are mostly the expected values from the Layout I specified
(time, log level, script name, hostname, PID, ?, message).
That's peculiar ... what does your layout look like?
It's hard to diagnose the problem without code that reproduces it, can
you post a stripped-down version of your appender?
I attached the appender code (full version), a configuration file, and a
test program in the first post I made. I could understand how you'd
want a stripped-down version of the appender :)
I wasn't sure what would happen if I stripped it down -- but it turns
out that even with only two subs defined (new and post_init), the
appender exhibits the problem of persistent DB connections.
The stripped-down version of DBI_Buffer is attached, along with the test
program and config. (again, modify the database config to match your
database).
For the error called 7 bind variables when 6 are needed..., I added a
little debug to DBI.pm (while still using my subclassed appender). With
the l4_depends_on code in the stripped-down DBI_Buffer.pm i.e.:
if ($self-{errorappender}) {
# Pass back the appender to be synchronized as a dependency
# to the configuration file parser
push @{$p{l4p_depends_on}}, $self-{errorappender};
push @{$p{l4p_post_config_subs}}, sub { $self-post_init() };
}
Then $p in DBI::calculate_bind_values shows the message as an array, e.g.:
calculate_bind_values Dump p:
$VAR1 = {
'log4p_level' = 'INFO',
'log4p_category' = 'ANS.component',
'level' = 1,
'name' = 'Database',
'message' = [
'Starting '
]
};
I thought the message array ref would get compressed to a scalar string
value, but that doesn't seem to be the case.
I tried messing with the warp_message values of the Logfile and Database
appenders, but I still end up with 7 bind values no matter what
warp_message setting I use.
--
Rob
package DBI_Buffer;
use base (Log::Log4perl::Appender::DBI);
use strict;
use warnings;
use Time::HiRes;
use Data::Dumper;
use vars qw ($VERSION);
$VERSION = 1.06;
##
sub new {
###
my($proto, %p) = @_;
my $class = ref $proto || $proto;
my $self = bless {}, $class;
$self-_init(%p);
my %defaults = (
reconnect_attempts = 1,
reconnect_sleep= 0,
logbuffer = 2000,
buffer = [],
connected = 1,
errorstodatabase = 1,
signal_caught = 0,
);
for (keys %defaults) {
if(exists $p{$_}) {
$self-{$_} = $p{$_};
} else {
$self-{$_} = $defaults{$_};
}
}
#e.g.
#log4j.appender.DBAppndr.params.1 = %p
#log4j.appender.DBAppndr.params.2 = %5.5m
foreach my $pnum (keys %{$p{params}}){
$self-{bind_value_layouts}{$pnum} =
Log::Log4perl::Layout::PatternLayout-new(
{ConversionPattern = {value =
$p{params}-{$pnum}}});
}
#'bind_value_layouts' now contains a PatternLayout
#for each parameter heading for the Sql engine
$self-{SQL} = $p{sql}; #save for error msg later on
$self-{MAX_COL_SIZE} = $p{max_col_size};
$self-{BUFFERSIZE} = $p{bufferSize} || 1;
$self-{errorappender} = $p{errorappender} if exists $p{errorappender};
$self-{errorstodatabase} = $p{errorstodatabase} if exists
$p{errorstodatabase};
$self-{flushsignal} = $p{flushsignal} if exists $p{flushsignal};
if ($self-{flushsignal}) {
#$self-{watcher} = Log::Log4perl::Config::Watch-new(
#file = '/dev/null', # no file needed
#signal = $self-{flushsignal}
#);
# Install a signal handler
$SIG{$self-{flushsignal}} = sub {
$self-{signal_caught} = 1;
print STDERR __PACKAGE__.: We get signal!\n;
$self-flush;
$self-{signal_caught} = 0;
}
}
# Run our post_init method in the configurator after
# all appenders have been defined to make sure the
# appenders we're connecting to really exist.
if ($self-{errorappender}) {
push @{$p{l4p_post_config_subs}}, sub { $self-post_init() };
}
if ($p{usePreparedStmt}) {
$self-{sth} = $self-create_statement($p{sql});
$self-{usePreparedStmt} = 1;
}else
Re: [log4perl-devel] subclassed DBI (DBI_Buffer) does not release dbh filehandles on reinit
Robert Jacobson wrote:
If I add equivalent code to my existing conditional for the definition
of errorappender, i.e.:
if ($self-{errorappender}) {
# Pass back the appender to be synchronized as a dependency
# to the configuration file parser
push @{$p{l4p_depends_on}}, $self-{errorappender};
push @{$p{l4p_post_config_subs}}, sub { $self-post_init() };
}
Then I get this error from Log::Log4perl::Appender::DBI:
Log4perl: DBI appender failed to reconnect to database after 1 attempt
at init_and_watch.pl line 10
I added some debug to DBI.pm and found that when I add the depends_on
code, the sub in DBI query_execute gets called with extra arguments. I
turned on the warn to print out the DBI::errstr and found that it isn't
really a connection error, it's a failure to execute the DBI statement:
Exe: failed: called with 7 bind variables when 6 are needed at
.../Log/Log4perl/Appender/DBI.pm line 159.
(line number different because of my local edits to DBI.pm)
Adding a Dumper for qmarks:
$VAR1 = '2009-055/17:35:41';
$VAR2 = 'INFO';
$VAR3 = 'component.pl';
$VAR4 = 'ansdev2';
$VAR5 = '25227';
$VAR6 = 'ARRAY(0x813274c)';
$VAR7 = 'Starting ';
Those are mostly the expected values from the Layout I specified (time,
log level, script name, hostname, PID, ?, message).
Where the heck did that ARRAY string come from? I checked using
ref(); it really is a string of characters and not an actual array ref.
--
Rob
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] Intermittent problems when using signal to reread log configuration
Ah, apparently I *had* left some appenders using DBI_Buffer (DBI appender subclass) in my config. I retested a bunch of things today and I could not reproduce the error unless I had my DBI_Buffer appender in the config. Further investigation showed that the mysql server was reaching its maximum number of allowed connections (currently set at 250). Apparently my appender is not closing its dbh filehandles. I'm going to start a separate thread, since the problem is something totally different (in my code, probably). I apologize for my inadequate testing :( -- Rob -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ log4perl-devel mailing list log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] Intermittent problems when using signal to reread log configuration
Mike Schilli m-at-perlmeister.com |log4perl_sourceforge| wrote: On Fri, 20 Feb 2009, Robert Jacobson wrote: I wonder what kind of config change would cause this. Are you removing an appender by any chance? Nope, usually I'm only changing the log level. But I can reproduce the error without changing anything in the config, too. Interesting ... is there a way you could send a narrowed-down test program to let me reproduce this? I can try, but it'll have to wait until I'm at work again. I'd be interested to find out what's causing this. Also, is this only happening on Windows with ActiveState Perl or have you seen it happen on other OS and perl distros as well? I am using ActiveState perl on CentOS 4.2 and RHEL4; they both exhibit the problem. I haven't tried Windows; does SIGHUP even exist there? (nvm, doesn't matter :) ) -- Rob -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ log4perl-devel mailing list log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel
