Hi peoples,

How does the ADO.Net appender handle intermittent connections?

I’m assuming that it’s holding a connection open and appending?

I have <bufferSize value=”0”> set to ensure an immediate call to a stored proc for logging.

So basically, do I need to worry about whether or not my connection to the other end exists?

Could the lack of a network connection translate to a pause in the app when the log statement gets written?

Or is all logging an asynchronous thread that doesn’t affect the caller?

Thanks in advance.

Hadley

Thanks for getting back to me Ron.

Okay, that’s good news, that it’ll try and reopen the connection.

We tend to use buffer size of 0 to avoid any build up, so I’m not sure I’d gain anything by using the Rhino-tools logging, but thanks for bringing it to my attention.

Regards

Hadley

Actually,

I was just thinking about TCP timeouts and lockups to the caller.

Is the log4net logging done in a separate thread to the caller?

If the connection to the DB goes away, it’s good that it’ll reconnect, but during that connection time, how does log4net handle the timeout?

Thanks

Hadley

Hi all,

I’ve done some testing by writing a small test app that loops through, throws an ArgumentException, gets caught and logs the exception to log4net.

My config has both a local file appender and an ADO Net appender.

There’s an artificial Sleep for a second in the loop so that it doesn’t just race by.

I’ve placed a StopWatch around the log4net call and set ReconnectOnError to true.

The behaviour I’m seeing is that the reconnect gets done every few seconds.

At the end of the email is a section of my console output from the test.

I unplugged the network cable at around 20 and plugged it back in at 50 there was a total of 120 loops.

During the disconnection there’s delays of up to 15s as a reconnection attempt is made.

Two questions.

1. Is it possible to specify how long to wait between reconnection attempts? Eg.  DelayBetweenReconnectionSeconds=”60”  eg, wait a minute before trying to reconnect again.
2. Given the delays, I’d say the reconnection attempt is a blocking call… Is there any way this can be an asynchronous call that changes the connected state flag if it succeeds? This would allow for a fast return of the log attempt. Yes, the message being logged is lost, but it doesn’t halt the calling code and introduce delays into the application.

Thanks in advance.

Hadley

Timing⎘] (6)ms

Timing⎙] (3)ms

Timing⎚] (10)ms

Timing⎛] (3)ms

Timing⎜] (3)ms

Timing⎝] (6)ms

Timing⎞] (3)ms

Timing⎟] (8)ms

Timing⎠] (9446)ms

Timing⎡] (14830)ms

Timing⎢] (14830)ms

Timing⎣] (7)ms

Timing⎤] (6)ms

Timing⎥] (6)ms

Timing⎦] (6)ms

Timing⎧] (14830)ms

Timing⎨] (6)ms

Timing⎩] (6)ms

Timing⎪] (6)ms

Timing⎫] (6)ms

Timing⎬] (6)ms

Timing⎭] (6)ms

Timing⎮] (6)ms

Timing⎯] (6)ms

Timing⎰] (6)ms

Timing⎱] (14829)ms

Timing⎲] (14830)ms

Timing⎳] (14829)ms

Timing⎴] (6)ms

Timing⎵] (6)ms

Timing⎶] (6)ms

Timing⎷] (6)ms

Timing⎸] (14829)ms

Timing⎹] (14829)ms

Timing⎺] (6)ms

Timing⎻] (6)ms

Timing⎼] (6)ms

Timing⎽] (6)ms

Timing⎾] (41554)ms

Timing⎿] (8)ms

Timing⏀] (3)ms

Timing⏁] (3)ms

Timing⏂] (3)ms

Timing⏃] (3)ms

Hi all,

Shortly after that last email, I went and read the docs for the ReconnectOnError

http://logging.apache.org/log4net/release/sdk/log4net.Appender.AdoNetAppender.ReconnectOnError.html

I changed my connection string to have “Connect Timeout=1” so that there’s only 1 sec for a connection timeout.

This helped reduce the lag noticeably on a reconnect.

Still, it would be nice if I could control the time between reconnection attempts and if the connection stuff happened in its own thread.

Regards

Hadley