|
Simon, I believe it was done some work on that in 1.2.9 (you are using
an earlier version, right?) I checked the source code for the AdoNetAppender, and in
the SendBuffer it tries to do a reconnect (if the parameter reconnectonerror is
stated in the config). override protected void SendBuffer(LoggingEvent[] events) { if (m_reconnectOnError && (m_dbConnection == null
|| m_dbConnection.State
!= ConnectionState.Open)) { LogLog.Debug("AdoNetAppender:
Attempting to reconnect to database. ((m_dbConnection==null)?"<null>":m_dbConnection.State.ToString())
); InitializeDatabaseConnection(); InitializeDatabaseCommand(); } Problem is that when I tested this (I restarted SQL server
between two log statements), I still gets an exception stating a “transport
layer error”. I agree with you, Simon this is a problem with applications
running for a long time for example web applications. A simple solution would
be to modify the adonetappender and try to do a reconnect whenever the sql statement
fails (I will give it a try). Regards Georg http://www.l4ndash.com
Log4Net Dashboard / Log4Net Viewer -----Original Me 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 proce 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 Me Subject: RE: Database Appender From: "Nicko Cadell"
<nicko () neoworks ! com> Date: 2005-01-10 13:59:27 Me [Download me 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 i 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 i 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 i 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 discu Nicko > -----Original Me > From: Ismay, Greg (CALBRIS) > [mailto:[EMAIL PROTECTED] > Sent: 10 January 2005 04:15 > To: [email protected] > 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 acce > 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 lo > > 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 > > > > > |
- Database Appender Ismay, Greg \(CALBRIS\)
- RE: Database A... Nicko Cadell
- RE: Database A... Simon Wallis
- RE: Databas... Georg Jansen
- RE: Database Ap... Ron Grabowski
- RE: Database Ap... Bejugam, Raghavendra \(GE Commercial Finance, NonGE\)
- RE: Databas... Georg Jansen
- RE: Database Ap... Bejugam, Raghavendra \(GE Commercial Finance, NonGE\)
- RE: Databas... Georg Jansen
- RE: Database Ap... Simon Wallis
- RE: Databas... Georg Jansen
