Log4j arrête soudainement la journalisation

Vous ai fourni quelques informations de base, donc je ne peux qu'esquisser quelques candidat causes et probabilité:

1. Problème avec fichier, serrures et poignées de/IO flux

• Triggerred par le journal le roulement?

  Négatif dans votre cas. Vos deux fichiers journaux (info et debug) arrêter en même temps pour une même GUERRE.
  Chaque fichier roule à la taille maximale par défaut (10 MO). Il est très peu probable que les deux journaux toujours rouler en même temps. L'erreur ne doit pas être déclenchée par le journal de roulement. Supplémentaire de confirmation par la configuration de log4j.appender.InfoAppender.MaxFileSize=200MB

• Triggerred par les utilisateurs de manipuler les fichiers Linux?

  Négatif dans votre cas. Il est possible que l'utilisateur/administrateur (trice) de manipulation de fichiers pourrait créer des serrures ou obsolètes aux descripteurs de fichiers. Linux ne devrait jamais avoir de problèmes avec un utilisateur queue-ing un fichier (mais sous windows). Linux peut avoir des problèmes avec les utilisateurs de la compression ou de la modification de fichiers. Mais ton problème semble très reproductibles, faisant de cet improbable sauf si vous avez des scripts automatisés de manipuler les fichiers de log.

• Triggerred par la "compétitivité" des paramètres de configuration de Websphere ou au Printemps, avec des doublons de fichiers journaux de serveur/cadre?

  Semble peu probable dans votre cas. Semble que vous n'avez pas été mise en Websphere communes de configuration de l'enregistrement. Commons logging est automatiquement inclus dans le serveur websphere chargeur de classe parent et peut être configuré pour "envelopper" de par la configuration de Log4J:

  Fichier commons-logging.propriétés

  # 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

• Déclenchée par des problèmes matériels/panne de disque?

  ??? Semble étrange qu'un tel problème serait très reproductible.

2. Problème avec les threads java?

• fil de la mort ou de blocage

• fil massif de traitement/conflit dans le code "autre", de sorte que le code avec l'exploitation forestière n'est pas exécuté

  À partir de votre description, je suppose que l'application est toujours en cours d'exécution et fonctionne bien avec la normale de performance et de fonctionnalité, mais les journaux ne sont pas écrites. Pouvez-vous confirmer? Si oui, alors c'est pas un thread problème avec la webapp threads.

  Aussi, je peux confirmer que ce n'est pas un thread de problème au sein de la Log4J logique, parce que la seule fois qu'il crée/utilise son propre thread, c'est quand l'un des AsynchAppender/ExternallyRolledFileAppender/SocketAppender/TelnetAppender est utilisé OU lorsque PropertyConfigurator.configureAndWatch ou DOMConfigurator.configureAndWatch méthode est appelée.

  c'est à dire Négatif.

3. Les changements de classes Log4J dans les chargeurs de classe, avec l'utilisation de différentes configuration?

• Chargeur de classe Parent des affrontements avec la Webapp chargeur de classe

  E. g. Votre webapps commencent avec leur propre configuré classes de répertoire web-inf et c'est tout bon, mais plus tard, après un certain temps une application différente des causes (ou de l'une de du serveur de portail des outils d'administration) provoque un cliquetis de la classe à être chargés dans le chargeur de classe parent et votre application à la "ramasse" cette nouvelle version illégale de la classe et échoue.

  Tout à fait peut-être un problème - des milliers d'utilisateurs sur Google ont lutté avec Websphere classe chargeurs.

D'Action Suggéré:

• vous assurer que toutes vos applications web utilisent PARENT_LAST ClassLoading - accédez à la console d'administration et de s'assurer qu'ils ont PARENT_LAST ensemble dans TOUS les WebApp configurations

• s'assurer que vous obtenez Log4J des messages d'erreur interne écrit dans la console
  E. g. Délibérément test par forceably supprimer le journal des erreurs en tant qu'admin, tandis que l'application est en cours d'exécution, la création d'un état de la poignée. Si "Log4J:" messages d'erreur n'apparaissent pas dans la console, alors c'est un problème grave.
  
  La prochaine fois que le problème se produit, le piège de ces messages sur la console et de les signaler. Aussi, vous pouvez définir l'option "-D log4j.debug" sur la JVM/websphere démarrage, pour savoir précisément ce que Log4J était en train de faire avant/pendant le problème - messages aller à la console.

• avez-vous vraiment besoin de définir le niveau de journalisation de DÉBOGAGE pour tous vos forfaits & classes? Mieux pour régler à l'INFO ou de l'AVERTIR et seulement définie de manière sélective lorsque vous déboguez des problèmes spécifiques?

C'est beaucoup de texte.......... B^)

Je pense que le problème, c'est que vous avez plusieurs Guerres écrit sur le même fichier journal. Dans notre expérience, log4j ne peut pas le faire de manière fiable, en particulier avec les rolling appenders. Quand on va à rouler, les autres sont confus et impossible de se connecter aux autres. Ou continuer à se connecter à l'ancien fichier.

Je soupçonne que vous allez avoir à chaque GUERRE du journal dans un fichier différent.

Je ne suis pas sûr pourquoi log4j est en cours d'arrêt dans votre application. Mais vous pouvez (devez) mettre à niveau à log4j 2.0. De commutation ne doit pas être trop d'effort. Vous aurez besoin de réécrire votre log4j.les propriétés de fichier pour un fichier XML parce que la nouvelle version ne prend pas en charge les propriétés de fichier plus.

Dans le Java Magazin un article a déclaré que log4j 2.0 se comportent de façon plus robuste dans les environnements multithreads, alors il ya une chance qu'il va corriger votre problème. Si ce n'est pas vous avez encore le bénéfice de la nouvelle version.

Il apporte quelques fonctionnalités intéressantes, et les améliorations (copié à partir de la log4j site):

API Séparation

L'API Log4j est distincte de la mise en œuvre de la rendre plus claire pour les développeurs d'applications les classes et les méthodes qu'ils peuvent utiliser tout en assurant la compatibilité ascendante. Cela permet à l'Log4j équipe afin d'améliorer la mise en œuvre en toute sécurité et de façon compatible.

Amélioration De La Performance

Log4j 2 effectue plus rapidement que Log4j 1.x dans les domaines critiques et de même pour Logback dans la plupart des circonstances. Voir les Performances pour plus d'informations.
Prise en charge de plusieurs Api
Alors que les 2 API Log4j offrir les meilleures performances, Log4j 2 fournit un support pour la SLF4J et Commons Logging Api.

Rechargement automatique des Configurations

Comme Logback, Log4j 2 peut recharger automatiquement sa configuration lors de la modification. Contrairement à Logback, il le fera sans perdre de journal des événements, tandis que la reconfiguration.

De Filtrage Avancé

Comme Logback, Log4j 2 prend en charge le filtrage basé sur les données de contexte, des marqueurs, des expressions régulières, et d'autres composants dans le Journal des événements. Le filtrage peut être spécifié de façon à s'appliquer à tous les événements avant d'être transmise au Enregistreurs ou qu'ils passent à travers les Appenders. De plus, les filtres peuvent également être associés avec les Bûcherons. Contrairement à Logback, vous pouvez utiliser un Filtre commun de la classe dans l'une de ces circonstances.

Architecture De Plugin

Log4j utilise le pattern de plugin pour configurer les composants. En tant que tel, vous n'avez pas besoin d'écrire du code pour créer et configurer un Appender, la Mise en page, Modèle de Convertisseur, et ainsi de suite. Log4j reconnaît automatiquement les plugins et les utilise lors de la configuration des références.

Support De La Propriété

Vous pouvez faire référence à des propriétés dans une configuration Log4j va remplacer directement, ou Log4j de les passer à un composant sous-jacent qui permettra de résoudre dynamiquement. Propriétés viennent de valeurs définies dans le fichier de configuration, propriétés système, variables d'environnement, le ThreadContext Carte et données présents dans l'événement. Les utilisateurs peuvent personnaliser la propriété des fournisseurs en y ajoutant leur propre Recherche de Plugin.