3

ApplicationChangeMonitor現在実行されているjarファイルの変更についてファイルシステムを監視するを実装したいと考えています。変更が検出されると、アプリケーションを再起動する必要があります。変更を検出するためにWatchServiceを使用しています。

セットアップ:

  • samba 共有上のワークスペースを使用した (Windows) Eclipse での開発 (Linux システム)
  • jar ファイルは、その samba 共有で Eclipse maven (m2e) によって生成されます。
  • jar ファイルは、Linux システムのシェルから実行されます (openjdk を使用)。

そのため、新しい jar ファイルが作成されるたびに、実行中のアプリケーションを Linux システムで再起動する必要があります。最初に、アプリケーション自体を再起動しようとしましたが、ほとんどの場合、JVM から致命的なエラーが発生しました。次に、より単純なアプローチを選択しました。変更が検出された後にアプリケーションを終了させ、bash で再起動メカニズムを実装しました。

while true ; do java -jar application.jar ; done

奇妙なことに、アプリケーションの変更後も致命的なエラーが 1 回か 2 回発生します。例：

  • java -jar application.jar <-- 初期起動、アプリケーションが実行中
  • 新しいjarファイルが作成されました
  • java -jar application.jar <-- 致命的なエラー
  • java -jar application.jar <-- 致命的なエラー
  • java -jar application.jar <-- アプリケーションの起動
  • 新しいjarファイルが作成されました
  • java -jar application.jar <-- 致命的なエラー
  • java -jar application.jar <-- アプリケーションの起動

出力：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f46d5e2416d, pid=28351, tid=139942266005248
#
# JRE version: 7.0_25-b30
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libzip.so+0x516d]  Java_java_util_zip_ZipFile_getZipMessage+0x114d
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/workspace/.../target/hs_err_pid28351.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

OpenJDK はダンプ ファイルを作成します。関連する部分は、この致命的なエラーにつながるスタック トレースだと思います。

 - Stack: [0x00007fbc9398f000,0x00007fbc93a90000],  sp=0x00007fbc93a8bd90,  free space=1011k
 - Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
 - C  [libzip.so+0x516d]  Java_java_util_zip_ZipFile_getZipMessage+0x114d
 - C  [libzip.so+0x5eb0]  ZIP_GetEntry+0xd0
 - C  [libzip.so+0x3af3]  Java_java_util_zip_ZipFile_getEntry+0xb3
 - j  java.util.zip.ZipFile.getEntry(J[BZ)J+0
 - j  java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+38
 - j  java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2
 - j  java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
 - j  sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+48
 - j  sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53
 - j  java.net.URLClassLoader$1.run()Ljava/lang/Class;+26
 - j  java.net.URLClassLoader$1.run()Ljava/lang/Object;+1
 - ...

さて、なぜこれらの致命的なエラーが発生するのか、誰にも分かりますか? おそらくjarファイルが完全に書き込まれていないためだと思いました（これにより、問題の原因が説明されますJava_java_util_zip_ZipFile_getZipMessage）。しかし、jar の md5sum は実行後も同じままであり、致命的なエラーが発生して実行が機能するため、そうではありません。

while true; do md5sum application.jar ; java -jar application.jar ; done
4

1 に答える 1

2

これは、そのファイルがディスクに書き込まれている間に、新しいファイルについて通知を受けているためです。これは WatchService の悪い点です。新しいファイルが作成されるとすぐに通知されますが、まだディスクに完全に書き込まれていません。

新しい jar ファイルがディスクに書き込まれているとき、その jar ファイルは、その jar ファイルをディスクに書き込んでいるプロセスによってロックされます。ファイル作成プロセスがファイルのロックを解除しない限り、ファイルにアクセスできません。

これに対する解決策: ファイルを開こうとする必要があります。ファイルが開かれた場合、ファイルはディスクに完全に書き込まれています。ファイルを開けない場合は、しばらく待ってから (または待たずに次へ)、次にファイルを開いてみてください。

ファイルのロックを解除するには、次のように実装します。

public void unlockFile(String jarFileName){
    FileInputStream fis = null;
    while(true){
        try{
            // try to open file
            fis = new FileInputStream(jarFileName);
            // you succeed to open file
            // return
            // file will be closed in finally block, as it will always executed
            return;
        }catch(Exception e){
            // file is still locked
            // you may sleep for sometime to let other process finish with file and
            // file gets unlocked

            // if you dont have problem with this process utilizing CPU, dont sleep!
            try{
                Thread.sleep(100);
            }catch(InterruptedException ie){
            }
        }finally{
            if(fis != null){
                try{
                    fis.close();
                }catch(Exception e){
                }
            }
        }
    }

あなたの問題に、

あなたは言った：「変更が検出された後にアプリケーションを終了させ、bashで再起動メカニズムを実装しました」

したがって、Javaプロセスを終了する前に、上記の方法で私が提案したようにファイルのロックを解除してください。エラーは確実になくなると思います。試してみて、結果を教えてください。

このようなもの：

void shutDownMethod(){
    // get file name from watcher, below line will depend on your logic and code.
    String jarFileName = watcherThread.getNewNotifiedFile();
    // unlock new jar file.
    unlockFile(jarFileName);
    // shutdown JVM
    System.exit(0);
    // bash will restart JVM
}
于 2013-10-18T10:40:15.750 に答える