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.
> 

Reply via email to