4

I'm using Log4perl as part of a package to capture what a particular DBI connection is doing. My current plan is to create a new logger object for each connection, via Log::Log4perl->get_logger($mysql_connect_id), which should allow the various connections to write to either different files or the same file without screwing each other up.

My concern is over what happens when the connection is disconnected and that logger is no longer needed. If Log4perl just keeps these loggers around indefinitely, that sounds like a recipe for a memory leak.

What's the best way to get rid of a logger after I'm sure it's no longer useful? Or, conversely, is this even a problem -- does Log4perl have some sort of built-in disposal mechanism that already prevents this sort of leak?

Edit: Mentioned in a question's comments, probably worth mentioning here: Log::Log4perl::Logger has a DESTROY method that seems promising. However, it's undocumented and throws a bunch of "Use of uninitialized value in string eq" warnings, which makes me wary; it feels like a hack. (But if that IS the best/only way to do it, I suppose the question becomes "How do I turn off a specific warning coming from a specific package?")
BlairHippo
  • 9,502
  • 10
  • 54
  • 78
  • 1
    [`DESTROY`](http://perldoc.perl.org/perlobj.html#Destructors) method should not be called manually, because it'll be caller by perl itself when object is going to be removed from memory. Calling `DESTROY` directly will not free the memory. – Ivan Nevostruev May 06 '11 at 17:09
  • @Ivan: Well, crap. So much for a perfectly good-looking hack. Thanks for the tip. – BlairHippo May 06 '11 at 17:14
  • 1
    Logger objects are a small hash of code references. Unless you're making tons of the things, I'd posit the extra memory is inconsequential compared to whatever actual data your program is storing in memory. Don't worry about it. – Schwern May 09 '11 at 06:38

4 Answers4

5

The only way I see is to manipulate the internal cache of Log::Log4perl::Logger.

delete $Log::Log4perl::Logger::LOGGERS_BY_NAME->{$category};

This is "safe" in that it will work with the current versions of Log::Log4perl, but not safe in that it could break in an update. This was previously suggested by another SO user but they deleted it.

I would suggest you make a feature request for the ability to delete individual cache entries as part of the API. If you want to expedite it, submit a patch. It's pretty straightforward.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • I've handled the problem by designing around it, but if I were still locked into the original design, this is the solution I'd use. And it's a good thing to have in my pocket. Thanks! (BTW -- I think we know each other in RL.) – BlairHippo May 10 '11 at 19:53
3

Sorry for the delay, I think I've finally fixed it now. You can now use a newly implemented method Log::Log4perl->remove_logger($logger) to delete unused loggers (don't forget to nuke the remaining reference of $logger you're holding).

Checked into github and should go out with the next release (1.33). Thanks for bringing this to my attention. Your log4perl guy, Mike.

Mr.Wizard
  • 24,179
  • 5
  • 44
  • 125
Mike Schilli
  • 31
  • 1
2

It looks like 

Log::Log4perl::Logger->cleanup();

call should remove everything initialized so far. It should remove any associated resources.

bvr
  • 9,687
  • 22
  • 28
  • Nuke the site from orbit? :-) That'd do it, but if I'm reading that correctly, that'll get rid of any loggers I want to keep around, too. – BlairHippo May 06 '11 at 19:56
  • @BlairHippo - did read your question incorrectly, I thought you want to get rid of Log::Log4perl completely. If you want to remove just something, why not just give it new config and let itself to reinitialize? – bvr May 07 '11 at 08:52
  • It's unfortunate that `cleanup()` doesn't just delete its own cache, it aggressively calls DESTROY on each logger. This is unnecessary and makes calling `cleanup()` dangerous. You have to know that all loggers everywhere in the entire process, even in 3rd party modules, are no longer in use. – Schwern May 09 '11 at 06:47
  • I've reported the problem of cleanup's aggressive behavior to the author. https://github.com/mschilli/log4perl/issues/7 (Also, cleanup is not documented so you shouldn't be using it) – Schwern May 09 '11 at 07:01
0

From the docs at http://search.cpan.org/dist/Log-Log4perl/lib/Log/Log4perl.pm :

To remove a logger from the system, use Log::Log4perl->remove_logger($logger). After the remaining reference $logger goes away, the logger will self-destruct. If the logger in question is a stealth logger, all of its convenience shortcuts (DEBUG, INFO, etc) will turn into no-ops.

buster
  • 1,071
  • 1
  • 10
  • 15
  • Heh. If you read the other answers, that feature is a consequence of this question. I'm actually kinda proud. :-) – BlairHippo Dec 02 '11 at 16:58