logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Wallis" <mail...@wallis.ca>
Subject RE: Database Appender
Date Thu, 02 Feb 2006 15:31:29 GMT
Hi,

Has anyone come up with any creative ways to solve this problem of the database connection
hanging? The only thing I can think of is to have a process that "touches" the config file
on an hourly basis. Otherwise we have to remember to go around doing this manually on all
the servers whenever the database is rebooted or there's a temporary network failure.

I realize it would be a lot of work to add retry or failure semantics to the appender, but
whenever this is implemented, likely the most flexible approach would be to provide a number
of options via the config file.

Simon.


-----Original Message-----
Subject:    RE:  Database Appender
From:       "Nicko Cadell" <nicko () neoworks ! com>
Date:       2005-01-10 13:59:27
Message-ID: DDEB64C8619AC64DBC074208B046611C59C838 () kronos ! neoworks ! co ! uk
[Download message RAW]

Greg,

The AdoNetAppender does not reopen the connection if there is a failure.
The database connection is only opened during appender initialisation.
Error handling is a general issue for appenders but for the
AdoNetAppender there are a number of options. 

The current behaviour is for the appender to stop trying to write to the
database if the connection is closed. An alternative is for the appender
to try to reconnect to the database. The issues with reconnecting is
when to try and how many times. The appender could try to reconnect when
the buffered events are sent. If it fails to contact the server then the
connection will time out after some time. This is a synchronous call and
therefore any logging call in your application could randomly incur this
connection timeout penalty at any time. Is that acceptable behaviour for
the appender? If the appender cannot reconnect should it discard the
events that it cannot deliver? or should it store the events and
redeliver them when/if it does reconnect, if so how many event should it
store?

There are no easy solutions to these issues, and different behaviours
will be appropriate for different situations. The current AdoNetAppender
implementation does not attempt to support any retry or failure
semantics. This is one area where we will need to do some work in
future. If you have any suggestions we would be happy to discuss them. 

Nicko

> -----Original Message-----
> From: Ismay, Greg (CALBRIS) 
> [mailto:Greg.Ismay@comalco.riotinto.com.au] 
> Sent: 10 January 2005 04:15
> To: log4net-user@logging.apache.org
> Subject: Database Appender
> 
> 
> > howdy everyone...
> > 
> > im using the database ADONetAppender to log to a sql server 
> database and its all going peachy keen... for a while...
> > 
> > ive got the same app installed at 4 of our sites, with the 
> appender pointing back to a central database accessible over 
> the wan (i will probably end up using a local db at each 
> site, but a central db was my going in position, with a "lets 
> see how it goes before we decentralise" mentality). the wans 
> pretty fast and im only doing production logging (ie only 
> errors and fatals) this way.
> > 
> > basically, it works for a few days and sometimes up to a 
> week or so, before the logging just stops.
> > 
> > forcing the loggers to reinitialised (ie by "touch"ing the 
> log4net.config file) makes it all good again...
> > 
> > my question is this... are there any known problems with the db 
> > appender (or any appender) whereby a loss of connection (which can 
> > happen over the wan) over time could result in the above 
> state (eg... 
> > maybe running out of connections in the pool due to them gradually 
> > getting "stuck")
> > 
> > ill troll through the code in a few minutes, but just 
> thought id ask first.
> > 
> > thanks,
> > 
> > Greg Ismay
> > 
> > Specialist - Database Support (Automation Improvement) Comalco 
> > Aluminium Limited
> > 
> > Phone 	:   +61 7 3867 1853
> > Fax    	:   +61 7 3867 1855
> > Mobile	:   +61 4 1760 6429
> >
> 


Mime
View raw message