1

私のプロジェクトでは何らかの理由で、このコマンド「gcc file.c -o file.exe」をJava EEサーバーで実行する必要があり、このJavaコードを使用しました

try {  
        Runtime runtime = Runtime.getRuntime();
         String[] cmd={"cmd.exe","/C gcc " + a +".c" + " -o "+b};
         Process p = runtime.exec(cmd,null,null );
        try {
            BufferedReader reader = new BufferedReader(new InputStreamReader(p.getErrorStream()));
            String line = null;
            try {
               while((line = reader.readLine()) != null) {
                       System.out.println(line);
                }
            } finally {
                reader.close();
            }
        } catch(IOException ioe) {
            ioe.printStackTrace();

        }


        } 
    catch (Exception e) {System.out.println("erreur d'execution"); }

}

コマンドは cmd で完全に機能し、このコードは Java アプリケーションで完全に機能し、出力 (.exe) とエラーを取得します。

後で（JBossサーバーを使用して）サーバーにデプロイしようとしても、何も起こりませんでした。後でサーバーからcmdを実行しようとしましたが、何も起こりませんでした。つまり、Java EE サーバーの問題のようなものです。

どうすれば修正できますか？このコードを実行できる Tomcat などの他のサーバーはありますか?

4

1 に答える 1

2

まず、runtime.exe を使用してプロセスを生成すると、さまざまな理由で EJB 仕様に違反します。したがって、彼らが言うように、銃を片手に弾丸をもう一方の手に持っており、これを行うことの意味を理解していなければ、簡単に自分の足を撃つことができます.

このコードをサーブレット (選択した JavaEE コンテナーにデプロイしたまま) に移動して、より仕様に準拠させることもできますが、アプリがクラスター化された環境で実行された場合に、クラスター化された環境ですべてがどのように機能するかを理解する必要があります。DB トランザクションの範囲内で対話するプロセスが必要な場合は、さらに多くの問題がありますが、それは要件の 1 つではないと仮定します。

これらの警告が邪魔にならないようにすると、現在のアプローチには大きな欠陥があり、無差別にスレッドのデッドロックが発生します。プロセスを開始するときは、STDOUT/STDERR ストリームを独自のスレッドで管理して、2 つのスレッド間でデッドロックが発生する可能性なしにバッファーが排出されるようにする必要があります。ここではそれを行っていません。プロセスを開始したのと同じスレッドから InputStream を読み取っているだけです。「何も起こらない」とあなたが言うとき、それはここで起こっていることである可能性が非常に高い. サーバー プロセスのスレッド ダンプを取りましたか?

このようなデッドロックを回避するには、ある時点で発生するので、ここで概説されているようなパターンを使用してください:なぜ runtime.exec() がハングするのか

于 2013-04-23T17:01:26.307 に答える