Несколько процессов, использующих один файл журнала блокировки приложения - PullRequest
Новая
       28

Несколько процессов, использующих один файл журнала блокировки приложения

3 голосов
/ 03 августа 2011

Мы используем блок приложения ведения журнала в нашем приложении 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

Существует несколько файлов журнала, созданных приложением, все типа "Rolling Flat File Trace Listener"

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

1 Ответ

5 голосов
/ 05 августа 2011

Из: 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

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

...