Re: [log4perl-devel] appender/dispatcher that writes to per-category files
On Tue, 6 Nov 2007, Jonathan Swartz wrote:
> >> Right, I expected that new categories would keep cropping up. Why
> >> would it be a problem for an appender to open new filehandles on
> >> the fly? Other than worrying about maximum # of filehandles?
> >
> > Categories are added at init() time, not at log() time. If you add
> > a new
> > category to Log4perl, you have to run init().
>
> Huh? I can add a category at runtime like
> my $log = Log::Log4perl->get_logger('foo.bar.baz');
> without having declared foo.bar.baz at init() time.
Ah, I see, we're talking about different things. I was talking about
adding categories and associate appenders with them. You're adding
them to the hierarchy and rely on category inheritance.
> I think you mean that categories are associated with appenders at init
> () time, right? But I'm not looking to create a ton of different
> appenders. I'm looking to create a single appender that handles all
> categories, and automatically writes to the right filename based on
> the category passed to log().
So you want a custom appender that dynamically changes the file it's
writing to. Since the appender's log() function gets 'log4p_category' in
its %param hash, this should be straight-forward to implement.
Sounds like an interesting idea, I'm looking forward to it!
-- Mike
Mike Schilli
[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] appender/dispatcher that writes to per-category files
> So you want a custom appender that dynamically changes the file it's > writing to. Since the appender's log() function gets > 'log4p_category' in > its %param hash, this should be straight-forward to implement. > > Sounds like an interesting idea, I'm looking forward to it! > Heh, no doubt. :) My main worry is number of open file handles. Especially with mod_perl, since a lot of those handles will be opened individually in the child processes. At the same time, I don't want to have to open and close each handle every time. Any idea what kind of limits on number of open handles I can expect to hit on a reasonable Unix system? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ log4perl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] appender/dispatcher that writes to per-category files
On Fri, 9 Nov 2007, Jonathan Swartz wrote:
> My main worry is number of open file handles. Especially with
> mod_perl, since a lot of those handles will be opened individually in
> the child processes. At the same time, I don't want to have to open
> and close each handle every time. Any idea what kind of limits on
> number of open handles I can expect to hit on a reasonable Unix
> system?
Depends. The easiest way to find out is this one:
#!/usr/bin/perl -w
use strict;
my @handles;
my $count;
while(1) {
open my $fh, "> http://get.splunk.com/
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] appender/dispatcher that writes to per-category files
Mike Schilli wrote: > On Fri, 9 Nov 2007, Jonathan Swartz wrote: > >> My main worry is number of open file handles. Especially with >> mod_perl, since a lot of those handles will be opened individually in >> the child processes. Any idea what kind of limits on >> number of open handles I can expect to hit on a reasonable Unix >> system? > > Depends. The easiest way to find out is this one: ... > > prints > > died at 1020 at ./t line 7. > > so that's it :). I think he was looking for the total number of open file handles per system, not per process. Try this: cat /proc/sys/fs/file-max - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ log4perl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] Log::Log4perl::initialized() but not really?
On Wed, 7 Nov 2007, Robert Raisch wrote:
> I'm probably missing something obvious here, but it seems
> counterintuitive to me to have
> use Log::Log4perl;
>
> my $config = '/dev/null';
>
> eval { Log::Log4perl::init($config) };
> die "Log::Log4perl::init failed:$@" if $@;
This is a valid configuration, albeit a suspicious one:
Log::Log4perl configuration looks suspicious: No loggers defined at
Config.pm line 307.
It's empty, so it does nothing :).
> if ( Log::Log4perl::initialized() ) {
> Log::Log4perl::get_logger()
> ->logdie("hmm, log4perl thinks it's been
> initialized");
> }
> pass the eval() and then logdie() using an uninitialized logger.
Actually, while this logger doesn't have an appender associated with it,
it is a valid logger.
> Wouldn't it be better to move line 113 in Config.pm
> $Log::Log4perl::Logger::INITIALIZED = 1;
> to the end of Log::Log4perl::Config::_init(), after L4p has been
> successfully initialized?
This wouldn't change anything since there's no "return" in between,
right?
That being said, I've found a bug in Config.pm that threw a warning
message on empty configurations, fixed in 1.14.
Thanks for the note ...
-- Mike
Mike Schilli
[EMAIL PROTECTED]
>
> Thanks much.
>
> Log::Log4perl/1.13, perl 5.8.0, RHEL ES3/Taroon
> Log::Log4perl/1.12, ActiveState perl 5.8.8/bin822, WinXP/SP2
>
> --
> Rob Raisch, Financial Media Holdings Group, Inc.
> Publishers of "Compliance Week" -- http://www.complianceweek.com/
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> log4perl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
