views:

18

answers:

1

We have a very simple ASP.Net page for uploading a file to our webserver. The page has no controls - a client uses it to automatically send us a file each night.

On occasion, the file seems to not get to us, but the client reports that they have sent it.

We added some logging statements to the page, and discovered something quite odd. The page ceases to execute right in the middle of a log statement. No exceptions, just up and dies.

Here is the code-behind:

protected void Page_Load(object sender, EventArgs e) {
    try {
        // record that request came in at all
        log.Debug("Update Inventory page requested through HTTP {2} on {0} {1}", DateTime.Now.ToShortDateString(), DateTime.Now.ToLongTimeString(), IsPostBack ? "POST" : "GET");

        // make sure directory exists
        string basePath = Server.MapPath("~/admin/uploads/");
        log.Debug("Saving to folder {0}", basePath);

        if (!Directory.Exists(basePath)) {
            log.Debug("Creating folder {0}", basePath);
            Directory.CreateDirectory(basePath);
        }

    // generate a unique file name
        string fileName = DateTime.Now.Ticks.ToString() + ".dat";
        string path = basePath + fileName;
        log.Debug("Filename to save is {0}", fileName);

    // record initial bytes of stream/file
    StreamReader reader = new StreamReader(stream);
    string fileContents = reader.ReadToEnd();

    log.Debug("File received by GET is " + fileContents.Length + " characters long and begins with: " 
        + Environment.NewLine + fileContents.Substring(0, Math.Min(fileContents.Length, 1000)));

    // write out file
    File.WriteAllText(path, fileContents);

        log.Debug("Update Inventory page processing finished.");
        // trap for and record any and all exceptions
    } 
    catch (Exception ex) {
        log.Debug(ex);
    }
}

The processing seems to die in the middle of the log statement that outputs the length and first portion of the fileContents variable. The logging that occurs when the process fails looks like this:

2010-08-02 02:46:01.7342|DEBUG|UpdateInventory|Update Inventory page requested through HTTP GET on 8/2/2010 2:46:01 AM
2010-08-02 02:46:01.7655|DEBUG|UpdateInventory|Saving to folder c:\hosting\sites\musicgoround.com\wwwroot\admin\uploads\
2010-08-02 02:46:01.7811|DEBUG|UpdateInventory|Filename to save is 634163139617811250.dat
2010-08-02 02:48:02.3905|DEBUG|UpdateInventory|

I really don't understand what to make of this.

I assume if there was a error in the transmission of the file that either an exception would be thrown from the reader.ReadToEnd() line. And if not an exception, I would expect the page processing to continue but that I may only receive part of the file (in which case it should log something).

The logging statement is only accessing a string variable, and it's inside a try-catch. NLog is the logging component we use, and we access that through the facade provided by the Simple Logging Facade project on Codeplex. So, we trust the logging component to be more or less bulletproof - we certainly don't see anything in our usage of it here that should be causing problems.

So, what's the deal? Why on earth could this page just up and stop processing like this?

The fact that we get a half-finished logging statement seems to point towards an error being swallowed in the logging system - but that just seems so unlikely - and we have NLog's internal logging on and it is not reporting any problems.

A: 

The most likely candidate is that this line:

2010-08-02 02:48:02.3905|DEBUG|UpdateInventory|

Is caused by this:

log.Debug(ex);

I.e. it is throwing an exception, but the logger is not recording anything useful. Why don't you try switching about the log levels a bit, e.g. change the exception logging level to error:

log.Error(ex);

That way you can see if it is actually throwing an exception and it is just the logger not recording the exception string properly.

Ben Robinson
Oh my ... your answer prompted me to double-check the NLog config file and our server version doesn't match our dev version - specifically, the layout isn't there and by default NLog doesn't include exception details in the log layout. What an oversight ...
qstarin
Te he, most people have had a similar problem at some point. At least the problem now makes sense ;-)
Ben Robinson