信頼できない C ライブラリがあります (頻繁にクラッシュする可能性があるという意味で)。これを Java プロセスから呼び出しています。
Java アプリ全体をもたらす C ライブラリでのクラッシュを防ぐため。このライブラリ専用の Java プロセスを生成し、Java アプリとのインターフェイスを確立するのが最善であると考えました。ソケットプログラミングまたは RMI を介して。その後、クラッシュが発生した場合は、別のクラッシュを生成して処理を続行できます。
ProcessBuilder行く方法はありますか？または、他に簡単な方法はありますか？
ありがとう！
はい、別の Java プロセスでネイティブ コードをホストすることが、アプリケーションをネイティブ コードから保護する唯一の方法です。
簡単な方法については、実装のわずかな違いだけです。たとえば、Java アプリケーションからコードを生成せず、自動起動するように構成されたネイティブ ラッパーでネイティブ コードをラップします。C とソケットの知識があれば、これによりソリューションが簡素化されます。このアプローチでは、RMI は最良の選択ではありません。
ネイティブ コードを Java でラップしたとしても、私は RMI を選びません。WAN 上の Windows でネットワークの問題が発生しました。コミュニケーションはできればシンプルに。データが複雑すぎる場合は、おそらく基本的なシリアル化ライブラリです。XML ルートをたどる場合、いくつかの選択肢があります。やり過ぎですが、http サーバーと Web サービス層を埋め込むこともできます。システム要件はわかりませんが、
復興は、さまざまな課題を生み出します。応答しなくなったら、別のプロセスを生成するだけですか...何回それを行うつもりですか... Javaからのプロセス管理には、多くのことが望まれています。
もっと簡単な方法を知りません。
親と子の間の対話には、RMI やソケットは使用しません。Process オブジェクトを介してアクセスできる、子の標準入力および出力ストリームを使用します。これはシンプルで、効率的で、プライベートです。ID、アドレス、認証などを考慮しなくても、ストリームをソケット ストリームとまったく同じように使用できます。自分でプロトコルを作成することも、Thrift や Protocol Buffers などを使用してエンティティ定義からプロトコルを構築することもできます。
パフォーマンスが問題ではなく、他のアプリケーションが「ネイティブ」サービスにヒットする可能性がある場合は、RESTful またはその他の種類の Web サービス指向の方法を使用します。クラッシュ時の再スポーンに関する限り、他の人が述べたように、プロセスをサービスとしてスポーンするだけで問題ありません。
アプリケーションがこのネイティブ サービスにヒットする唯一のエンティティである場合は、純粋なソケットの方法ではなく、RMI の方法を使用することをお勧めします。IMO、RMI はプロセス間通信 (プロセスが Java プロセスである場合) に自然に適合します。RMI には、「アクティブ化可能な」リモート オブジェクトの概念があり、要件があれば自然に適合します (クラッシュ時の自動生成)。また、RMI を使用する場合、アプリケーションは、アドホック プロトコル コントラクトではなく、明確に定義された Java インターフェイスを介してネイティブ プロセスと通信します (これは、Web サービスなどの他の高レベル ソリューションを使用して実現できますが、生のソケットに関しては非常に困難です)。 .
ところで、JFTR、私たちはプロダクション アプリでこの戦略を使用しており、YMMV は非常にうまく機能しています。:-)