locked
How to tell if a call to log4net.ILog.InfoFormat() is successful? RRS feed

  • Question

  • How can a program confirm if a call to log4net.ILog.InfoFormat() successfully writes to a file?

    A client has a program that uses an ILog interface instantiation to write to a text file. The current program will happily accept a non-existent path and then silently fail. The client wants to be notified of a failure to write but I do not see any way to do that given the available methods in the interface.


    Richard Lewis Haggard

    • Moved by Kristin Xie Wednesday, January 27, 2016 2:50 AM third-party product
    Friday, January 22, 2016 12:33 AM

Answers

  • I ended up solving the problem by brute force. The app.config file contains the specification for both the 'local' and 'remote' output file names as fully qualified paths. I wrote code that opened the app.config in the same fashion as any other XML file and then parsed through the nodes until it found the one that contained the 'remote' output filename. The code then stripped out the path and saved that in a property that could be accessed by the method that was supposed to output a string to that file. The first thing the method did was to verify that it was possible to write to the destination folder before it attempted to write out the line of text to the real destination file. This was constructed in this fashion because the output only happened once every few minutes at the most and the line that was being written is the result of an important operation that could conceivably cost the company thousands of dollars if it were to be accomplished incorrectly. The consumers of this program are happy with the results so all is well in Whoville again.

    Richard Lewis Haggard

    Tuesday, February 9, 2016 5:05 PM

All replies

  • You mean to say that you can't do a try/catch on Log4net and if it throws an error, start sending an email?
    Friday, January 22, 2016 4:21 AM
  • The operation doesn't appear to throw an exception or return anything.

    The problem is that it is possible to specify a net location for where the destination file should reside but then the users sometimes fail to remember that the machine needs to actually be on the network which sort of makes it a bit more difficult for the machine to successful access the destination. I was thinking that I would try to extract the destination location from the configuration file and then use that path to determine if the destination is available and if the destination file itself was updated.


    Richard Lewis Haggard

    Friday, January 22, 2016 6:13 PM
  • From reading it looks like the caller needs to request the log to be forced.  (I have underlined where it says that.)

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa746557%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    ILog File-based Implementation

    The Windows operating system provides a file-based implementation of ILog, which enables you to create a log suited for write-ahead logging on a file. The log uses a file as a circular buffer, which enables unused space to be reused. This may also increase the size of the file that may be needed to fit additional records when the log is full. Changes to the log are made atomically, so that the contents of the log may be recovered after a crash. This implementation uses a buffer in memory for appending log records. As a result, records are not guaranteed to be written to disk when the ILog::AppendRecord method returns, unless the caller requests that the log be forced.


    Friday, January 22, 2016 10:52 PM
  • Let be restate the problem. What determines where the log is written? The essence of the problem is that the write operation can fail if the destination path is not available. The simplistic solution is to extract the path and explicitly verify the availability of the destination. So, what are the elements in the application configuration file that determine where the destination will be for the logs?

    Richard Lewis Haggard


    Monday, January 25, 2016 4:00 PM
  • That depends on what the name of the setting if one is.  If you have the source code you should be able to look in the "app.config" and view it.  It's just xml.
    Monday, January 25, 2016 5:03 PM
  • These forums are for MS products.  Please post questions related to third party products like Log4Net in their forums.
    Monday, January 25, 2016 5:14 PM
  • He is using the "ILog" interface.  Does that make it relevant to be posted here?  
    Monday, January 25, 2016 5:27 PM
  • He is using the "ILog" interface.  Does that make it relevant to be posted here?  

    Nope Log4Net is a 3rd party tool. my be the OP will get some help.

    http://apache-logging.6191.n7.nabble.com/Log4net-Dev-f23387.html

    • Proposed as answer by Kristin Xie Wednesday, January 27, 2016 2:50 AM
    Monday, January 25, 2016 6:00 PM
  • I ended up solving the problem by brute force. The app.config file contains the specification for both the 'local' and 'remote' output file names as fully qualified paths. I wrote code that opened the app.config in the same fashion as any other XML file and then parsed through the nodes until it found the one that contained the 'remote' output filename. The code then stripped out the path and saved that in a property that could be accessed by the method that was supposed to output a string to that file. The first thing the method did was to verify that it was possible to write to the destination folder before it attempted to write out the line of text to the real destination file. This was constructed in this fashion because the output only happened once every few minutes at the most and the line that was being written is the result of an important operation that could conceivably cost the company thousands of dollars if it were to be accomplished incorrectly. The consumers of this program are happy with the results so all is well in Whoville again.

    Richard Lewis Haggard

    Tuesday, February 9, 2016 5:05 PM