使用一个日志记录应用程序块日志文件的多个进程
我们在 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
应用程序生成了几个日志文件,所有类型均为“滚动平面文件跟踪侦听器
”有办法避免这种情况吗?
We use the logging application block in our ASP.NET 2.0 application which is called in the following way:
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();
}
}
When we increase the number of worker processes in IIS above 1 the log files are prepended with a unique GUID like this:
068aa49c-2bf6-4278-8f91-c6b65fd1ea3aApplication.log
There are several log files generated by the app all of type "Rolling Flat File Trace Listener"
Is there a way to avoid this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
最初来自:
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(稍微重写以提高清晰度):
基本上这似乎是一个已知问题,有一个解决方法
http://entlibcontrib.codeplex.com/workitem/7472
使用NoGUIDRollingFlatFileListener没有帮助,问题仍然发生(即使花费了大量时间重新编译日志记录应用程序块)。它很可能可以在 EntLib 4 中修复,但我坚持使用 Ent Lib 3.1
也许我应该考虑替代的日志记录机制
Originally from:
http://ykm001.springnote.com/pages/6348311?print=1
(now a dead link redirecting to a game site):Known problems
A GUID might be prepended to the filename of the log file
A RollingFileTraceListener instance "owns" the log file it is writing to and
locks it for exclusive write access when it writes the first log entry. It
keeps the file locked until the instance is disposed. If another
RollingFileTraceListener instance is created that points to the same file,
before the first instance is disposed, the second instance cannot open this
file for writing and will write to a new file with a GUID prepended to its
name.
The RollingFileTraceListener indirectly derives from
System.Diagnostics.TextWriterTraceListener. This class changes the filename to
include a GUID when the file with the specified filename cannot be written to.
This is because RollingFileTraceListener indirectly calls the EnsureWriter
method on its base class TextWriterTraceListener. .NET Reflector shows this
code for System.Diagnostics.TextWriterTraceListener.EnsureWriter() in
System.dll (slightly rewritten to improve clarity):
Basically it seems to be a known problem, there is a workaround at
http://entlibcontrib.codeplex.com/workitem/7472
Using the NoGUIDRollingFlatFileListener doesn't help, the problem still occurs (even after much time spent recompiling the logging application block). It might well be fixable in EntLib 4 but I'm stuck with Ent Lib 3.1
Perhaps I should look at alternative logging mechanisms