2

It took me a long time to track down a Log4Net configuration problem where the database connection string wasn't correct because when XmlConfigurator.Configure() was called in code, instead of throwing an exception it just hung.

It would have been easy to figure out fast if I had realized it was hanging on that particular line of code right away, but I was calling a wcf service that uses a behavior that uses log4net and of course it was configured correctly in the dev environment but not in the staging environment so it took longer to track down.

It really bothers me that it just hung instead of throwing an exception about the login not working. Is this some kind of bug in log4net?

BVernon
  • 3,205
  • 5
  • 28
  • 64
  • Unless someone comes along with a crystal ball, you're going to need to provide more information. Config files and the code you use to make the call, possibly the service implementation, etc. – Tim Aug 15 '14 at 21:10
  • @Tim False. See answer below. :) – BVernon Jan 09 '18 at 07:36

1 Answers1

2

No, it isn't a bug, it's the documented behaviour:

log4net is a best-effort and fail-stop logging system.

By fail-stop, we mean that log4net will not throw unexpected exceptions at run-time potentially causing your application to crash. If for any reason, log4net throws an uncaught exception, please send an email to the log4net-users@lists.sourceforge.net mailing list. Uncaught exceptions are handled as serious bugs requiring immediate attention.

If you want to check that your configuration is valid, the documentation suggests code like this:

To prevent silent failure of log4net, log4net supports a way to evaluate if it was configured and also to evaluate messages generated on startup since 1.2.11. To check if log4net was started and configured properly one can check the property log4net.Repository.ILoggerRepository.Configured and enumerate the configuration messages as follows:

if(!log4net.LogManager.GetRepository().Configured)
{
    // log4net not configured
    foreach(log4net.Util.LogLog message in 
             log4net.LogManager.GetRepository()
                    .ConfigurationMessages
                    .Cast<log4net.Util.LogLog())
    {
        // evaluate configuration message
    }
}
stuartd
  • 70,509
  • 14
  • 132
  • 163
  • 1
    Thanks. +1 for the explanation, but there's something I still don't understand. How is causing a deadlock 'better' than throwing an uncaught exception? At least I could ignore an uncaught exception in my own app and it wouldn't break it. But I can't do anything (reasonably practical) about a deadlock. It seems to me that that's actually worse than an uncaught exception, isn't it? – BVernon Aug 18 '14 at 15:00
  • I started to mark this the answer because it's the only one here, but I just can't. If "uncaught exceptions are handled as serious bugs requiring immediate attention" as you say, then causing a deadlock should be considered as a 10x more serious problem. – BVernon Dec 01 '14 at 20:33
  • You say in your question that the problem was that "the database connection string wasn't correct". How can that cause a deadlock? – stuartd Dec 01 '14 at 20:34
  • Are you asking why XmlConfigurator.Configure() would cause a deadlock when the connection string is incorrect? I obviously can't answer that because I didn't write Log4Net. – BVernon Dec 01 '14 at 22:58
  • I understand a deadlock to be when [two database operations conflict over accessing the same resource](http://technet.microsoft.com/en-us/library/ms177433(v=sql.105).aspx), which if the connection string isn't valid then obviously isn't possible. Log4net tries to establish a SqlConnection in the same way as any other code, so it will wait for the connection timeout set in the connection string to expire before failing (or 15 seconds, which is the default). This will block the current thread, as with all SqlConnections. – stuartd Dec 01 '14 at 23:13
  • 1
    While the term 'deadlock' isn't specific to database operations, I was using the term a bit more liberally than I should have. I just meant that my code waits for the Log4Net method to return and it never does. I didn't mean that any database operations were occurring. – BVernon Dec 02 '14 at 16:45
  • So 3 years later I get an upvote on this question and am now looking through comments and I think, if I remember correctly, that the problem was that someone thought the timeout parameter in cxn string was in milliseconds. I unfortunately didn't realize right away that someone had set the timeout to 15000 (which, I don't know why they did that since if they wanted 15 seconds that's the default anyway). So just wanted to say thanks for your help and sorry for being frustrated at you when the 'deadlock' was totally our fault. – BVernon Jan 09 '18 at 07:34