Log4j突然停止记录 [英] Log4j suddenly stops logging

问题描述

我正在构建一个部署到在Linux上运行的WebSphere Portal Server的Portlet应用程序。每个Portlet WAR使用Log4j进行日志记录，使用这样的配置，每个WAR都有两个日志文件：

I'm build a Portlet application deployed to a WebSphere Portal Server running on Linux. Every Portlet WAR uses Log4j for logging with a configuration like this, having every WAR two Log files:

log4j.logger.im.the.package=DEBUG, InfoAppender, DebugAppender

log4j.appender.InfoAppender=org.apache.log4j.RollingFileAppender
log4j.appender.InfoAppender.Threshold=INFO
log4j.appender.InfoAppender.File=/tmp/infoWARName.log
log4j.appender.InfoAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.InfoAppender.layout.ConversionPattern=%d %p [%c] - %m%n

log4j.appender.DebugAppender=org.apache.log4j.RollingFileAppender
log4j.appender.DebugAppender.Threshold=DEBUG
log4j.appender.DebugAppender.File=/tmp/debugWARName.log
log4j.appender.DebugAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.DebugAppender.layout.ConversionPattern=%d %p [%c] - %m%n

部署后，一切都像魅力和日志文件一样开始填充。几个小时后，同时，Logging停止并且 info.log 和 debug.log 不是完全更新。我们需要在服务器中重新部署Portlet WAR以重新开始记录。

After deployment, everything works like charm and log files started filling. After some hours, and at the same time, the Logging stops and info.log and debug.log aren't updated at all. We need to redeploy the Portlet WAR in the server to get the logging starting again.

任何想法？

更新：

我开始怀疑它与我的Logging JARS有关。目前，这是我的 WEB-INF / lib 文件夹中的JAR：

I'm starting to suspect it has to do with my Logging JARS. Currently, this are the JAR's inside my WEB-INF/lib folder:

com.springsource.org.apache.commons.logging-1.1.1.jar
com.springsource.org.apache.log4j-1.2.15.jar
com.springsource.slf4j.api-1.5.6.jar
slf4j-log4j12-1.5.6.jar

第二次更新：

从赏金到结束的时间，这就是每个Portlet应用程序中Log4j的配置方式。这是 web.xml ：

At hours from the bounty to end, this is how Log4j is configured in every Portlet Application. Here's web.xml:

<context-param>
    <param-name>log4jConfigLocation</param-name>
    <param-value>classpath:miAppLog4j.properties</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>

和 miAppLog4j.properties 文件位于WAR外部的文件夹和Portal。我们通过 WebSphere Portal中的共享库<在Portlet Classpath中创建了它/ a>。

And miAppLog4j.properties file is located in folder external to the WAR and to the Portal. We made it availbale in Portlet Classpath through a Shared Library in WebSphere Portal.

推荐答案

您已经提供了一些基本信息，因此我只能勾勒出一些候选原因和可能性：

You've provided some basic information, so I can only sketch some candidate causes and likelihood:

1。文件锁定/句柄/ IO流问题

• 通过日志滚动触发？

• Triggerred by log rolling?

在您的情况下为负。对于任何给定的WAR，您的两个单独的日志文件（信息和调试）会同时停止。
每个文件以默认的最大大小（10MB）滚动。这两个日志不太可能同时滚动。日志滚动不能触发错误。通过配置 log4j.appender.InfoAppender.MaxFileSize = 200MB进行额外确认

Negative in your case. Your two separate log files (info and debug) stop at the same time for any given WAR. Each file rolls at the default maximum size (10MB). It's very unlikely that both logs would always roll at the same time. The error must not be triggered by log rolling. Extra confirmation by configuring log4j.appender.InfoAppender.MaxFileSize=200MB

操作Linux文件的用户触发？

Triggerred by users manipulating Linux files?

您的情况为负。 user / sysadmin操作文件可能会创建锁或过时的文件句柄。 Linux应该永远不会遇到用户 tail -ing文件的问题（但是windows确实如此）。 Linux可能会遇到用户压缩或编辑文件的问题。但是你的问题似乎是非常可重复的，除非你有自动脚本操作日志文件，否则这个问题就不太可能了。

Negative in your case. It's possible that user/sysadmin manipulating files could create locks or stale file handles. Linux should never have problems with a user tail-ing a file (but windows does). Linux can have problems with users zipping or editing files. But your problem seems very repeatable, making this unlikely unless you have automated scripts manipulating log files.

由Websphere或Spring中的竞争配置设置触发，服务器/框架重复使用相同的日志文件？

Triggerred by "competitive" config settings in Websphere or Spring, with duplicate use of same log files by server/framework?

在您的情况下似乎不太可能。似乎您还没有设置Websphere commons日志记录配置。 Commons日志记录自动包含在websphere服务器父级ClassLoader中，并且可以配置为通过配置包装到Log4J：

Seems unlikely in your case. Seems you haven't been setting Websphere commons logging configuration. Commons logging is automatically included in the websphere server parent ClassLoader and can be configured to "wrap" to Log4J by configuring:

文件 commons-logging.properties

# Set application classloader mode as PARENT_LAST when deploying in WAS as .ear
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

由硬件问题/磁盘故障引发？

Triggered by hardware problems/disk failure?

??? 似乎很奇怪这样的问题会非常可重复。

??? Seems strange that such a problem would be very repeatable.

2。 java线程有问题吗？

• 线程死亡或死锁



• 大规模其他代码中的线程处理/争用，以便不运行带有日志记录的代码

• thread death or deadlock

• massive thread processing/contention in "other" code, so that code with logging is not run

从您的描述中，我假设应用程序仍在运行并且正常工作正常性能和功能，但不写日志。你确定吗？如果是这样，那么它不是webapp线程的线程问题。

From your description, I assume that the application is still running and working fine with normal performance and functionality, but the logs are not written. Can you confirm? If so, then it's not a thread problem with the webapp threads.

另外我可以确认它不是Log4J逻辑中的线程问题，因为唯一的时间当使用AsynchAppender / ExternallyRolledFileAppender / SocketAppender / TelnetAppender之一时，或者当调用PropertyConfigurator.configureAndWatch或DOMConfigurator.configureAndWatch方法时，它创建/使用自己的线程。

Also I can confirm that it isn't a thread problem within the Log4J logic, because the only time it creates/uses its own thread is when one of AsynchAppender/ExternallyRolledFileAppender/SocketAppender/TelnetAppender is used OR when PropertyConfigurator.configureAndWatch or DOMConfigurator.configureAndWatch method is called.

ie 否定。

3。 ClassLoader中Log4J类的更改，使用不同的配置？

• 父类ClassLoader与Webapp ClassLoader冲突

• Parent ClassLoader clashes with Webapp ClassLoader

例如您的webapps最初是从WEBINF目录中自己配置的类开始的，一切都很好，但是稍后一段时间后，一个不同的应用程序导致（或其中一个门户网站服务器管理工​​具）导致一个冲突类被加载到父ClassLoader和您的应用程序选择这个新的非法版本的课程并失败。

E.g. Your webapps initially start with thier own configured classes from WEBINF directory and all is good, but later after some time a different app causes (or one of the portal server admin tools) causes a clashing class to be loaded into the parent ClassLoader and your app "picks up" this new illegal version of the class and fails.

很可能是一个问题 - 谷歌上的数千名用户都在努力使用Websphere类加载器。

Quite possibly a problem - thousands of users on Google have struggled with Websphere class loaders.

建议采取的行动：

• 确保所有Web应用程序都使用PARENT_LAST ClassLoading - 转到管理控制台并确保它们在所有WebApp配置中设置了PARENT_LAST

• ensure all your web apps use PARENT_LAST ClassLoading - go to the Admin console and ensure that they have PARENT_LAST set within ALL WebApp configurations

确保您获得Log4J内部写入控制台的错误消息
例如故意在应用程序运行时通过强制删除错误日志作为管理员进行测试，从而创建过时的句柄。如果Log4J：错误消息没有出现在控制台中，那么这是一个严重的问题。

下次出现问题时，请捕获任何此类控制台消息并报告它们。此外，您可以在JVM / websphere启动时设置-D log4j.debug，以便准确地找出Log4J在问题发生之前/期间正在做什么 - 消息将转到控制台。

ensure you are getting Log4J internal error messages written to the console E.g. Deliberately test by forceably deleting the error log as admin while app is running, creating a stale handle. If "Log4J:" error messages do not appear in console, then this is a serious problem.
Next time the problem occurs, trap any such console messages and report them. Also, you can set "-D log4j.debug" on JVM/websphere startup, to find out precisly what Log4J was doing before/during the problem - messages will go to console.

您是否真的需要为所有软件包设置日志级别为DEBUG&班？最好设置为INFO或WARN，并且只在调试特定问题时选择性地设置？

do you really need to set the logging level to DEBUG for all of your packages & classes? Better to set to INFO or WARN and only selectively set on when you are debugging specific problems?

这是很多文本.......... B ^）

That's alot of text.......... B^)

这篇关于Log4j突然停止记录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！