Java の別のチームによって開発された C++ ライブラリと通信したいと考えています。
これまで見てきた自然で最適なアプローチは JNI を使用することですが、開発中は簡単にするために SWIG を使用します。
私たちは実際にプロトタイプを開発し、うまく機能しています。SWIG Director を使用した最初の Java->c++ 通信の後に、C++->Java 通信もあります。
これまで見てきた主な問題は、メモリ破損やメモリ リークなど、C++ ライブラリで発生する可能性のあるエラーにさらされることです。
これらのエラーから効果的に保護する方法はないようです。たとえば、C++ で中止 (不正なメモリ操作をシミュレート) を実行すると、JVM が強制終了されます。
私たちが考えた解決策は、JBoss で実行される親 JVM からいくつかの Java プロセスを起動することであり、それを保護したいと考えています。
基本的に、最初にJVMを起動する必要があるため、Javaプロセスの起動は困難です。
この場合、私たちが考えた解決策は、複数の Nailgun サーバーを使用することです。それぞれがJVM広告をロードし、起動したいプログラムに（クラスパスで）アクセスできます。
各 Nailgun サーバー (関係は 1-1) の各 JVM は、同じ JVM でプログラムの複数の実行を同時に実行できます。エラーが発生すると、この Nailgun JVM でのすべての実行がクラッシュします (ただし、JBoss JVM は動作します)。このため、実行数を制限したいくつかの Nailgun サーバーを用意し、何らかの負荷分散を使用して実行を任意のサーバーにディスパッチするようにスケジュールしました。さらに、メモリ リークを防ぐために、Nailgun サーバーは定期的に再起動されます。
これは、C++ のクラッシュから保護するための優れたアプローチであると考えています。
ただし、より良いアプローチがあるかどうかコミュニティに尋ねたいと考えています。
私たちが検討しているもう 1 つの解決策は、フェールオーバーの理由から、war に JBoss をクラスター化することです。そして、C++ プログラムの信頼性に応じて、Nailgun サーバーを組み込むかどうかを決定します。純粋な JBoss クラスター化アプリケーション (Nailgun プロセスなし) の利点は、プロセス間通信が一切必要なく、操作全体がスレッドを使用するプロセスで実行されることです。