web-dev-qa-db-ja.com

Log4jが突然ロギングを停止します

Linux上で実行されているWebSpherePortalServerにデプロイされたポートレットアプリケーションを構築しています。すべてのポートレットWARは、次のような構成でロギングにLog4jを使用し、すべてのWARに2つのログファイルがあります。

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はまったく更新されません。ロギングを再開するには、サーバーにポートレットWARを再デプロイする必要があります。

何か案は？

更新：

私はそれが私のロギングJARSに関係しているのではないかと疑い始めています。現在、これは私のWEB-INF/libフォルダー内のJARです。

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

2回目の更新：

報奨金から終了までの数時間で、これはすべてのポートレットアプリケーションでLog4jが構成される方法です。これが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およびポータルの外部のフォルダーにあります。 WebSphere Portalの共有ライブラリ を介して、ポートレットクラスパスで使用できるようにしました。

javalog4jwebsphere
14
Carlos Gavidia-Calderon

あなたはいくつかの基本的な情報を提供したので、私はいくつかの候補の原因と可能性をスケッチすることしかできません：

1。ファイルロック/ハンドル/ IOストリームの問題

  • ログローリングによってトリガーされますか？

    あなたの場合は否定的です。 2つの別々のログファイル（情報とデバッグ）は、特定のWARに対して同時に停止します。各ファイルは、デフォルトの最大サイズ（10MB）でロールします。両方のログが常に同時にロールされる可能性はほとんどありません。エラーはログローリングによってトリガーされてはなりません。 log4j.appender.InfoAppender.MaxFileSize=200MBを構成することによる追加の確認

  • Linuxファイルを操作するユーザーによってトリガーされますか？

    あなたの場合は否定的です。ユーザー/システム管理者がファイルを操作すると、ロックや古いファイルハンドルが作成される可能性があります。 Linuxでは、ユーザーtail-ファイルの作成に問題が発生することはありません（ただし、Windowsでは問題が発生します）。 Linuxでは、ユーザーがファイルを圧縮または編集する際に問題が発生する可能性があります。しかし、問題は非常に再現性が高いように思われるため、ログファイルを操作する自動スクリプトがない限り、これは起こりそうにありません。

  • サーバー/フレームワークによる同じログファイルの重複使用で、WebsphereまたはSpringの「競合する」構成設定によってトリガーされますか？

    あなたの場合はありそうもないようです。 Websphereコモンズのログ設定を設定していないようです。 Commonsロギングは、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スレッド？の問題

  • スレッドの死またはデッドロック

  • 「その他の」コードでの大規模なスレッド処理/競合。ログ付きのコードは実行されません。

    あなたの説明から、アプリケーションはまだ実行されており、通常のパフォーマンスと機能で正常に動作していると思いますが、ログは書き込まれません。確認できますか？もしそうなら、それはwebappスレッドのスレッドの問題ではありません。

    また、Log4Jロジック内でスレッドの問題ではないことも確認できます。これは、独自のスレッドを作成/使用するのは、AsynchAppender/ExternallyRolledFileAppender/SocketAppender/TelnetAppenderのいずれかが使用されている場合のみであるためですOR = PropertyConfigurator.configureAndWatchまたはDOMConfigurator.configureAndWatchメソッドが呼び出されたとき。

    つまり負。

。異なる構成を使用したClassLoadersのLog4Jクラスへの変更？

  • 親ClassLoaderがWebappClassLoaderと衝突する

    例えば。 Webアプリは、最初はWEBINFディレクトリから独自に構成されたクラスで始まり、すべて問題ありませんが、しばらくすると、別のアプリが原因で（またはポータルサーバー管理ツールの1つで）、競合するクラスが親のClassLoaderとアプリに読み込まれます。クラスのこの新しい違法バージョンを「ピックアップ」して失敗します。

    おそらく問題です。Googleの何千人ものユーザーがWebsphereクラスローダーに苦労しています。

推奨されるアクション：

  • すべてのWebアプリがPARENT_LASTClassLoadingを使用していることを確認します-管理コンソールに移動し、すべてのWebApp構成内でPARENT_LASTが設定されていることを確認します

  • log4Jの内部エラーメッセージがコンソールに書き込まれていることを確認します。アプリの実行中に管理者としてエラーログを強制的に削除し、古いハンドルを作成して、意図的にテストします。 「Log4J：」エラーメッセージがコンソールに表示されない場合、これは重大な問題です。
    次に問題が発生したときに、そのようなコンソールメッセージをトラップして報告します。また、JVM/websphereの起動時に「-Dlog4j.debug」を設定して、問題の前/問題中にLog4Jが何をしていたかを正確に調べることができます。メッセージはコンソールに送信されます。

  • すべてのパッケージとクラスのログレベルをDEBUGに設定する必要が本当にありますか？ INFOまたはWARNに設定し、特定の問題をデバッグするときにのみ選択的に設定する方がよいでしょうか。

それはたくさんのテキストです.......... B ^）

22
Glen Best

Log4jは、5年以上の間、バグがほとんど修正されていません。事実上、死んだプロジェクトです。許容できる場合は、Logbackに置き換えることを検討してくださいこれはSLF4jを直接実装します。

LogbackとSLF4Jは、Log4J（Ceki）を書いたのと同じ人によって書かれ、さらに自由なライセンスを持ち、優れたコミュニティを持っています。これは、可能な限りすべての点でLog4J 1の後継です（名前を除く）。

5
Geoffrey De Smet

問題は、同じログファイルに複数のWARが書き込んでいることだと思います。私たちの経験では、log4jは、特にローリングアペンダーでは、これを確実に行うことはできません。 1つがそれを転がすために行くとき、他は混乱して、それ以上ログに記録することができません。または、古いファイルへのログインを続行します。

各WARログを異なるファイルに記録する必要があると思います。

3
dbreaux

ログファイルの場所を一時ファイルシステム以外の場所に移動してみます。

0
GreyBeardedGeek