我建立部署在Linux上运行的WebSphere Portal Server中的Portlet应用程序。 每个portlet WAR使用log4j对于这样的配置记录，让每WAR两个日志文件：
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
部署完成后，一切正常般的魅力和日志文件开始填写。 几个小时后，在同一时间，记录停止， info.log和debug.log不更新的。 我们需要重新部署的portlet WAR的服务器来获取日志重新开始。
有任何想法吗？
更新：
我开始怀疑它与我的日志罐子做的。 目前，这是在我的JAR的WEB-INF/lib文件夹：
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
第二次更新：
在从赏金到几个小时，这是Log4j的是如何在每一个Portlet应用程序配置。 这里的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文件所在文件夹外部的战争和门户。 我们在Portlet的类路径使其availbale通过共享库在WebSphere Portal中 。
您所提供的一些基本信息，所以我只能画出一些候选人的原因和可能性：
1.问题的文件锁/手柄/ IO流
通过日志滚动Triggerred？
负你的情况。 你的两个独立的日志文件（信息和调试）停止在同一时间对于任何给定WAR。 每个文件在卷默认最大大小（10MB）。 这是非常不可能的，这两种日志总是卷在同一时间。 错误绝不能日志滚动触发。 额外的确认通过配置log4j.appender.InfoAppender.MaxFileSize=200MB
由用户操作的Linux文件Triggerred？
负你的情况。 这有可能是用户/系统管理员操作文件可能会造成锁或过时的文件句柄。 Linux的不应该有一个用户尾巴 -ing文件的问题（但Windows一样）。 Linux可以与用户压缩和解或编辑文件的问题。 但你的问题似乎很重复，使得这种可能性不大，除非你有自动化脚本操作的日志文件。
由WebSphere或春“竞争力”的配置设置，由服务器/框架重复使用相同的日志文件Triggerred？
似乎不太可能在您的案件。 好像你还没有被设置的Websphere公共日志配置。 通用日志被自动包括在WebSphere服务器父ClassLoader和可以被配置为通过配置“包装”到Log4J的：
文件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
由硬件问题/磁盘故障引发？
??? 似乎很奇怪，这样的问题会很重复。
2.问题与Java线程？
- 线程死亡或死锁
海量线程处理/争中的“其他”代码，所以用日志记录代码不运行
从你的描述，我假定应用程序仍在运行，并与正常的性能和功能工作正常，但日志不会被写入。 你确定吗？ 如果是这样，那就不是一个线程问题的Web应用程序的线程。
我还可以确认它不是Log4J的逻辑中的一个线程问题，因为它创建唯一的时间/使用自己的线程是当使用AsynchAppender / ExternallyRolledFileAppender / SocketAppender / TelnetAppender的一个或当PropertyConfigurator.configureAndWatch或DOMConfigurator.configureAndWatch方法被调用。
即负 。
3.更改类加载器中的类Log4J的，与使用不同的配置呢？
父类加载器上有冲突的webapp的ClassLoader
例如，您的web应用最初从WEB-INF目录开始thier自己的配置类和一切都很好，但后来一段时间后，不同的应用程序的原因（或门户服务器管理工具之一），将造成撞击的类装载到父类加载器和您的应用“拿起”之类的新版本非法和失败。
很可能是一个问题 - 成千上万的用户在谷歌一直在努力与WebSphere类加载器。
建议的操作：
确保所有的Web应用程序使用PARENT_LAST类加载 - 到管理控制台，并确保它们具有PARENT_LAST所有Web应用程序的配置中设置
确保你得到写入控制台如故意测试通过forceably删除错误日志的管理，同时应用程序运行Log4J的内部错误消息，创建一个陈旧的手柄。 如果“Log4J的：”错误消息不会在控制台出现，那么这是一个严重的问题。
下一次出现问题，陷阱任何这样的控制台消息和举报。 此外，您还可以设置JVM / websphere的启动“-D log4j.debug”，找出precisly什么Log4J的是这个问题之前，期间做/ - 消息会去控制台。
你真的需要设置日志记录级别到调试的所有程序包和类的？ 最好设置为INFO或警告只有当你正在调试的具体问题上选择性地设置？
这是很多文字..........乙^）
在过去的5年中，Log4j的几乎没有任何错误修正：它有效地是一个死的项目。 如果接受， 考虑的logback，它直接实现SLF4J 取代它 。
的logback和SLF4J由谁写的Log4J（Ceki）同一个人写的，有一个更宽松的许可证，并具有良好的社区。 它在一切可能的方式（除了它的名字）的继任者Log4J的1。
我认为这个问题是你有多个WAR中写入相同的日志文件。 根据我们的经验是，log4j不能做到这一点可靠，特别是与滚动追加程序。 当一个人去滚吧，别人都搞不清楚，无法进一步记录。 还是继续登录到旧文件。
我怀疑你将不得不在每次战争日志到不同的文件。
我想尝试移动速度比临时文件系统中的其他日志文件位置的某处。
我不知道为什么log4j的在你的应用程序停止。 但是你可以（应该）升级到2.0的log4j。 开关不应该是很大的努力。 您需要将您的log4j.properties文件改写到一个XML文件，因为新的版本不支持属性文件的任何更长的时间。
在Java Magazin的一篇文章指出，log4j的2.0表现在多线程环境更加坚固，所以有机会的话，将解决您的问题。 如果没有你还有新版本的好处。
它带来了一些不错的功能和增强功能（从复制的log4j的网站）：
API分离
对于Log4j提供的API是从实现分离并明确了哪些类和方法，同时确保向前兼容性，他们可以使用应用程序的开发人员。 这使得Log4j的团队，提高执行安全和兼容的方式。
性能改进
Log4j的2执行的关键领域比Log4j的1.x的速度更快，同样在大多数情况下的logback。 有关更多信息，请参阅性能。 对于多个API支持，而Log4j的2 API将提供最佳的性能，Log4j的2提供了SLF4J和共享日志记录API的支持。
配置的自动重新加载
像的logback，Log4j的2能够自动重新加载时修改其配置。 不同的logback，它会这么做，而不会丢失日志事件而重新配置正在发生。
先进的过滤
像的logback，Log4j的2个支持筛选基于上下文数据，标记，正则表达式，以及其他部件在日志事件。 过滤可以指定被传递到记录仪或之前，他们通过附加目的地适用于所有事件。 此外，过滤器还可以与记录器相关联。 不同的logback，你可以在任何的这些情况下使用共同的过滤器类。
插件架构
Log4j的使用配置组件插件模式。 因此，你不需要编写代码来创建和配置的Appender，布局，模式转换器，等等。 Log4j的自动识别插件和使用它们时的配置引用它们。
属性支持
可以在配置引用属性是，log4j将直接替换它们，或将Log4j中它们传递到，将动态解决这些问题的基础组件。 属性来自存在于事件中的配置文件中定义的值，系统属性，环境变量的ThreadContext地图和数据。 用户可以通过添加自己查找插件进一步自定义属性供应商。
