Managing error conditions in appenders is difficult. As far as possible log4net should not intrude into the calling application, i.e. it should not leak unexpected exceptions, and it should not randomly block, or have excessively slow calls.
Deciding between fatal and recoverable errors is usually impossible. The current policy is to stop logging rather than intrude into the calling application. Some appenders are more prone to recoverable errors than others. Error recovery and appender failover is an area where we need to do a lot more work, however I think that we are going to need to coordinate with the other log4 projects on the general direction. I don't want to change the default behaviour of the AdoNetAppender, but I will add a configuration property that enables reconnection, at the potential cost of introducing connection timeouts. Nicko > -----Original Message----- > From: Burger, Erik [mailto:[EMAIL PROTECTED] > Sent: 27 January 2005 14:15 > To: 'Log4NET User' > Subject: RE: ADONetAppender through a firewall > > I am not referring to a faulty database server or network problems. > > Many companies (mine is one of them) reboot their servers at > least once a week. This is perfectly normal maintenance > policy. If the database goes offline and online constantly > then this is cleary a network problem and log4net should > indeed not be responsible for handling this. If the database > never comes online again, the same applies. > > If my database would go offline indefinately I would get very > very cranky indeed towards my support engineers. Not to > mention hundreds of users that would suddenly be unable to > use our system. > > Erik > > ------------------------------- > Software Engineer > Research and Development Group > GPXS Wireless Ltd. > Southampton, United Kingdom > Phone: +44 (0) 23 8076 2519 > Fax: +44 (0) 23 8076 2555 > Email: [EMAIL PROTECTED] > > > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 27, 2005 2:10 PM > To: Log4NET User > Subject: RE: ADONetAppender through a firewall > > > What happens if the database never comes back online? Are > messages held indefinietly? Should there be another threshold > that that tells log4net when to stop trying? log4net assumes > a certain level of stability with its loggers. I don't think > its the responsibility of log4net to handle a database > constantly going online and offline. If you're worried about > things like that perhaps you should use a different logging > destination. > > Should the logger I think what Nicko is trying to get at is > that log4net > > --- "Burger, Erik" <[EMAIL PROTECTED]> wrote: > > > Would it be an option to add a configurable parameter to the > > ADONetAppender that specifies a timespan between retries? > Perhaps in > > this case the buffer size should become dynamic so that no messages > > are lost. > > > > Just adding my two cents. I must admit to a degree of > naivity since I > > haven't looked at the actual code yet. > > > > Is there a development thread that is discussing this issue? > > > > Erik > > > > ------------------------------- > > Software Engineer > > Research and Development Group > > GPXS Wireless Ltd. > > Southampton, United Kingdom > > Phone: +44 (0) 23 8076 2519 > > Fax: +44 (0) 23 8076 2555 > > Email: [EMAIL PROTECTED] > > > > > > -----Original Message----- > > From: Nicko Cadell [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 25, 2005 1:55 AM > > To: Log4NET User > > Subject: RE: ADONetAppender through a firewall > > > > > > Dave, > > > > Out of interest what would happen if the AdoNetAppender could not > > connect to the database for some reason, lets say there is > a network > > connectivity error? Does this change mean that the appender > tries to > > connect each time a message is logged? Does this lead to a > 30 second > > blocking timeout for each logging call that is routed to > the appender? > > > > If so this is likely an unexpected and unreasonable burden > to place on > > the calling application. > > > > Nicko > > > > > -----Original Message----- > > > From: Dave Hutz [mailto:[EMAIL PROTECTED] > > > Sent: 24 January 2005 23:13 > > > To: [email protected] > > > Subject: ADONetAppender through a firewall > > > > > > We have been running into trouble while using > ADONetAppender to log > > > to a database that is behind a firewall. > > > > > > In short, the firewall times-out idle connections, and log4net > > > doesn't reconnect to the database once the connection is broken. > > > > > > I added some code like this, and it seems to fix the problem. > > > > > > /// <summary> > > > /// This method determines if there is a sense in attempting to > > > append. /// </summary> /// <remarks> /// <para> /// This method > > > checks if the db is open. If it isn't, it opens > > it. > > > /// </para> > > > /// </remarks> > > > /// <returns><c>false</c> if any of the preconditions > > > fail.</returns> override protected bool PreAppendCheck() { > > > if (!base.PreAppendCheck()) > > > { > > > return false; > > > } > > > if (m_dbConnection==null || > > > m_dbConnection.State!=ConnectionState.Open) > > > { > > > InitialiseDatabaseConnection(); > > > InitialiseDatabaseCommand(); //must reinitialize the > > > command if we redo the connection > > > } > > > return true; //it throws above if it fails } > > > > > > > > > > > > Could you include this (or something like it) into the main code? > > > > > > Thanks, > > > Dave > > > > > > > The information transmitted by this e-mail message is > intended solely > > for the use of the person to whom or entity to which it is > addressed. > > The message may contain information that is privileged and > > confidential. Disclosure, dissemination, distribution, review, > > retransmission to, other > > use of or taking any action in reliance upon this information by > > anyone > > other than the intended recipient is prohibited. If you are not the > > intended > > recipient, please do not disseminate, distribute or copy this > > communication, > > by e-mail or otherwise. Instead, please notify us immediately by > > return > > e-mail (including the original message with your reply) and then > > delete and > > discard all copies of the message. > > > > Although we have taken precautions to minimize the risk of > > transmitting viruses we nevertheless advise you to carry > out your own > > virus checks on any > > attachment to this message. We accept no liability for any loss or > > damage > > caused by viruses. > > > > The information transmitted by this e-mail message is > intended solely for the use of the person to whom or entity > to which it is addressed. The message may contain information > that is privileged and confidential. Disclosure, > dissemination, distribution, review, retransmission to, other > use of or taking any action in reliance upon this information > by anyone other than the intended recipient is prohibited. If > you are not the intended recipient, please do not > disseminate, distribute or copy this communication, by e-mail > or otherwise. Instead, please notify us immediately by return > e-mail (including the original message with your reply) and > then delete and discard all copies of the message. > > Although we have taken precautions to minimize the risk of > transmitting viruses we nevertheless advise you to carry out > your own virus checks on any attachment to this message. We > accept no liability for any loss or damage caused by viruses. > >
