Несколько процессов с использованием одного файла журнала блока приложения регистрации

Мы используем блок приложения для ведения журнала в нашем приложении ASP.NET 2.0, который вызывается следующим образом:

public class BaseLogEntry : LogEntry
{
    public void CloseLog()
    {
        try
        {
            Logger.Writer.Dispose();
        }
        catch (Exception)
        { }
    }
}

public class GeneralLogEntry : BaseLogEntry
{
    /// <summary>
    /// 
    /// </summary>
    /// <param name="message"></param>
    public GeneralLogEntry(string message) : this(message, 2) { }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="message"></param>
    /// <param name="priority"></param>
    public GeneralLogEntry(string message, int priority): base()
    {
        Categories.Add("General");
        Priority = priority;
        Severity = System.Diagnostics.TraceEventType.Information;
        Message = message;
        CloseLog();
    }
}

Когда мы увеличиваем количество рабочих процессов в IIS выше 1, к файлам журнала добавляется уникальный GUID, например:

068aa49c-2bf6-4278-8f91-c6b65fd1ea3aApplication.log

Приложение создает несколько файлов журналов типа "Слушатель трассировки непрерывных файлов".

Есть ли способ этого избежать?


iis asp.net-2.0 enterprise-library logging-application-block
person Gordon Thompson    schedule 03.08.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Источник: http://ykm001.springnote.com/pages/6348311?print=1 (теперь мертвая ссылка, перенаправляющая на сайт игры):

Известные проблемы

GUID может быть добавлен к имени файла журнала. Экземпляр RollingFileTraceListener "владеет" файлом журнала, в который он записывает, и блокирует его для монопольного доступа на запись, когда он записывает первую запись журнала. Он сохраняет файл заблокированным до тех пор, пока экземпляр не будет удален. Если создается другой экземпляр RollingFileTraceListener, указывающий на тот же файл, до удаления первого экземпляра, второй экземпляр не может открыть этот файл для записи и будет записывать в новый файл с идентификатором GUID, добавленным к его имени.

RollingFileTraceListener косвенно является производным от System.Diagnostics.TextWriterTraceListener. Этот класс изменяет имя файла, чтобы включить GUID, когда файл с указанным именем не может быть записан. Это связано с тем, что RollingFileTraceListener косвенно вызывает метод EnsureWriter своего базового класса TextWriterTraceListener. .NET Reflector показывает этот код для System.Diagnostics.TextWriterTraceListener.EnsureWriter () в System.dll (слегка переписан для большей ясности):

try
{
    this.writer = new StreamWriter(fileNameWithPath, true, encoding1, 0x1000);
    break;
}
catch (IOException)
{
    Guid guid1 = Guid.NewGuid();
    fileName = guid1.ToString() + fileName;
    fileNameWithPath = Path.Combine(folderPath, fileName );
}

По сути, это известная проблема, есть обходной путь

http://entlibcontrib.codeplex.com/workitem/7472

Использование NoGUIDRollingFlatFileListener не помогает, проблема все еще возникает (даже после долгой перекомпиляции блока приложения для ведения журнала). Это вполне может быть исправлено в EntLib 4, но я застрял в Ent Lib 3.1

Возможно, мне стоит взглянуть на альтернативные механизмы ведения журнала.

person Gordon Thompson    schedule 05.08.2011