log4perl-devel

Re: [log4perl-devel] Revisit of database logging when database connection fails

[Robert J. <yad...@sn...>]

LOL!  I always do this -- when I've explained the problem to someone 
else, I figure it out myself soon after!

My DBI_wrapper.pm is mimicking Appender::DBI already, in that it does 
_init() (connects to the database) on new() and calls 
Appender::DBI::log() to log the message.

I can change my new() to *not* call _init(); instead, I call _init() 
right before Appender::DBI::log(), then I disconnect.

Anyway, I think I've got it figured out now -- but if anyone sees 
problems with it, please let me know.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson               ..........................
Flight Ops. Team        Solar Dynamics Observatory (SDO)
.............                             ..............

Re: [log4perl-devel] Revisit of database logging when database connection fails

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

On Thu, 4 Jan 2007, Robert Jacobson wrote:

> LOL!  I always do this -- when I've explained the problem to someone
> else, I figure it out myself soon after!

That's the kind of problem I like hearing about :).

> My DBI_wrapper.pm is mimicking Appender::DBI already, in that it does
> _init() (connects to the database) on new() and calls
> Appender::DBI::log() to log the message.
>
> I can change my new() to *not* call _init(); instead, I call _init()
> right before Appender::DBI::log(), then I disconnect.

By the way, you might want to take a look at

   mysql_auto_reconnect
	  This attribute determines whether DBD::mysql will automatically
	  reconnect to mysql if the connection be lost. This feature
	  defaults to off; however, if either the GATEWAY_INTERFACE or
	  MOD_PERL envionment variable is set, DBD::mysql will turn
	  mysql_auto_reconnect on.  Setting mysql_auto_reconnect to on is
	  not advised if 'lock tables' is used because if DBD::mysql
	  reconnect to mysql all table locks will be lost.  This attribute
	  is ignored when AutoCommit is turned off, and when AutoCommit is
	  turned off, DBD::mysql will not automatically reconnect to the
	  server.

in the DBD::mysql manpage, wouldn't this solve your problem?

-- Mike

Mike Schilli
m...@pe...

> Anyway, I think I've got it figured out now -- but if anyone sees
> problems with it, please let me know.
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Robert Jacobson               ..........................
> Flight Ops. Team        Solar Dynamics Observatory (SDO)
> .............                             ..............
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] Revisit of database logging when database connection fails

[Robert J. <yad...@sn...>]

At 01:50 AM 1/8/2007, Mike Schilli wrote:

>By the way, you might want to take a look at mysql_auto_reconnect 
>[snip] wouldn't this solve your problem?

Perhaps it would.  I have to find out what happens when 
mysql_auto_reconnect is turned on, but the actual database or network 
connection is truly down.  Turning on reconnects within Appender::DBI 
caused my perl programs to block while waiting for the reconnection 
-- defeating the purpose of the queuing mechanism (i.e. don't block 
when the database is down!)

I think another problem with my existing code is that the connection 
my wrapper makes is totally separate from the connection that 
Appender::DBI makes.  So even if my wrapper notices the disconnect 
and makes the reconnection -- Appender::DBI still has to 
reconnect.  I still don't know why Appender::DBI failed to reconnect, 
but if the connections in my wrapper and the appender are separate, I 
can see that it makes the probability of error higher.

Perhaps the answer is to write a true subclass of Appender::DBI 
instead of the kludge I came up with.  I think I can just override 
the log() method with my own with something like:

# Begin simplistic Pseudocode
sub log ()
{
         if (not connected2database() ) {
                 # Connection is down
                 buffer_message()
         } else {
                 write2database(@buffered_messages)
         }
}

sub connected2database
{
         if (not $dbh->ping() )
         {
                 # try to reconnect - once
                 eval { connect() }
                 if ($@) {
                         # connection successful, rebuild statement handle
                         return 1;
                 } else {
                         return 0;
                 }
         }
}


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson               ..........................
Flight Ops. Team        Solar Dynamics Observatory (SDO)
.............                             ..............

Re: [log4perl-devel] Revisit of database logging when database connection fails

[Robert J. <yad...@sn...>]

I'm having a problem adding new configuration items to my subclass -- 
is it possible without copying the code from Appender::DBI::new() to 
add a new configuration item?  The code I tried (below) didn't work 
-- the new option "LOGBUFFER" did not appear because the %defaults 
hash in DBI.pm is basically throwing it away.

I would basically like to use the existing new() method in 
Appender::DBI, so I'm calling SUPER::new() in my subclass.

-----BEGIN subclass DBI_Buffer
package DBI_Buffer;
use base ("Log::Log4perl::Appender::DBI");

use strict;
use warnings;

sub new {
         my ($class, %options) = @_;

         my $self = {
                 LOGBUFFER => 2000,
                 %options,
         };

         bless $self, $class;

         return $self->SUPER::new(%options);
}


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson               ..........................
Flight Ops. Team        Solar Dynamics Observatory (SDO)
.............                             ..............