Log4j внезапно прекращает регистрироваться

Вы предоставили некоторую основную информацию, таким образом, я могу только делать набросок некоторых причин кандидата и вероятности:

1. Проблема с файлом locks/handles/IO поток

• Triggerred by log rolling?

  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

• Triggerred by users manipulating Linux files?

  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.

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

  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:

  File 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. Проблема с явскими нитями?

• thread death or deadlock

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

  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.

  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.

  i.e. Negative.

3. Изменения классов Log4J в ClassLoaders, с использованием различной конфигурации?

• Parent ClassLoader clashes with Webapp 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.

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

Предложенное действие:

• 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

• 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.

• 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^)

Больше 5 лет у Log4j есть едва любые исправленные ошибки: это - эффективно мертвый проект. Если приемлемый, считают замену его с Logback , который осуществляет SLF4j непосредственно.