0

みなさん、良い一日を。

次の問題を解決できません：

アプリケーションにはWebSphereアプリサーバーを使用し、ログファイルの管理には「ログバック」ログフレームワークを使用しています。

エブリシングは正常に機能しているように見えましたが、最近、ファイルローリングの許容できない動作が検出されました。WebSphereでのアプリケーションの最初の開始では、ログファイルのローリング（サイズ別および日別）は正常に機能しますが、アプリケーションを停止すると、現在のログファイルはjava.exe（IBM WAS）プロセスによってロックされ、アプリケーションを最初からやり直すと、以前のロックのため、ローリングログは機能しません。Unlockerを介してファイルを調べたとき、私は驚きました-現在のファイルをロックする2つのプロセスがありました。また、アプリを停止して再起動すると、現在のログファイルをロックするjava.exeが3つありますが、タスクマネージャーでは1つのプロセスしか実行されていません。このような「テスト」中にOutOfMemoryエラーが発生することがあります。

そのため、最後に非常に大きなログファイルがあります。（20GB以上）

私はいくつかの同様の問題を見つけましたが、log4jローリングに問題があります。そして、それがなぜそうだったのかについての説明はありません-ただ1つがそうでした-log4jはwebsphereには推奨されません。

そして、「ロガー」ではまったく問題がないようです。それで、2つの質問に答えることができる人はいますか？

  1. アプリケーションがすでに停止しているのに、WebSphereがファイルをロックして解放しないのはなぜですか？

  2. アプリケーションが正しい方法で停止されたときに（Unlocker、Task Managerなどのチートを使用せずに）ログファイルのロックを解除する（またはWebSphereにロックしないように指示する）方法は？

ご清聴ありがとうございました...どんな助けもいただければ幸いです。

更新1：

最近、私はログバック付きの小さなWebアプリを使おうとしましたが、繰り返しロックすることなく、うまく機能します。

また、大きなアプリケーションが停止したときにログを調べたところ、これが見つかりました（アプリケーションの停止中のログ内の唯一の文字列）

27-03 05:59:39 [WebContainer : 7] INFO o.hibernate.impl.SessionFactoryImpl:close - closing

閉じているが閉じていない？私は正しい方法で考えることを願っています...

----UPD 3

うーん...私はWebsphereにカスタムWARをデプロイするのに多くの時間を費やしましたが、それでも、WASがログファイルをロックする場合とロックしない場合がある理由を見つけることができません。

信じられない、同じトラブルに直面した人がいないことに驚いています

4

1 に答える 1

1

この記事は私を助けてくれます-http ://logback.qos.ch/manual/jmxConfig.htmlアプリではJMXConfiguratorsを使用していませんが...

だから私はweb.xmlに追加しました

<listener>
    <listener-class>ru.fns.commonex.listener.CleanUpServletContextListener</listener-class>
</listener>

リスナーには次のコードがあります：

@Override
public void contextDestroyed(ServletContextEvent sce) {
    log.debug("contextDestroyed({}) called.", sce);
    deRegisterLog();
}

/**
* Avoiding memory leaks
*
* If your application is deployed in a web-server or an application server,
* the registration of an JMXConfigurator instance creates a reference from the system class loader
* into your application which will prevent it from being garbage collected when it is stopped or re-deployed,
* resulting in a severe memory leak.
*
* Thus, unless your application is a standalone Java application,
* you MUST unregister the JMXConfigurator instance from the JVM's Mbeans server.
* Invoking the reset() method of the appropriate LoggerContext will automatically unregister any
* JMXConfigurator instance. A good place to reset the logger context is in the contextDestroyed()
* method of a javax.servlet.ServletContextListener.
*/
private void deRegisterLog() {
    LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
    log.info("Trying to stop logger factory {}", lc);
    if (lc != null) {
        lc.stop();
    }
}
于 2013-04-02T10:24:21.617 に答える