java - このシナリオでは、appdomainsが役立つ可能性がありますか？

Question

管理されていないdllへの呼び出しを介してJavaプロセスと通信しているdotnetプロセスがあります。

状況によっては、Javaプロセスがクラッシュし、dotnetプロセスがダウンしているように見えます。例外は発生せず、プロセスはただ終了します。クラッシュすると、javaは「hs_err_pid3228」などの名前のログファイルを作成します。

アンマネージDLLとJavaプロセスを提供しているベンダーから満足を得られなかったので、Javaプロセスへの呼び出しがクラッシュした場合でも、プロセスを停止しないようにする必要がある問題を軽減しようとしています。 。

さまざまな記事を読んだことで、appdomainsを使用する可能性が高いようです-私の理論では、Javaプロセスを呼び出す機能を少しの作業で分離し、別のappdomainで実行できます。これにより、appdomainをキャッチできない場合でも可能になると思います。ダウンしている場合は、少なくともそれが発生したことを検出し、その機能を再起動します。

誰かが同じような問題を抱えていましたか？このアプローチは、appdomainの経験が豊富な方にとっては合理的だと思いますか？

さらに楽しくするために、Javaのクラッシュは実際には再現可能ではありません-それは非常にランダムに見え、appdomainへの分離をテストする方法とまだ戦っています

Answer 1

これはAppDomainsの合理的な使用法であり、提案したものは機能します。

同様に、私はかつてAppDomainsを使用して、例外レポートの目的でクラッシュするのを監視する単一のアプリケーションを作成しました。アプリケーションはそれ自体を起動し、新しいAppDomainを作成してから、新しいAppDomainで再実行しました。これにより、アプリケーションがAppDomainで実行されていることを検出し、正常に実行されました。そのAppDomainで例外が発生すると、元のプロセスに通知され、エラーが発生したことをユーザーに報告する子ドメインを破棄し、報告するかどうかを尋ねてから、自分自身を取得して再試行します。

編集：あなたに有利なスタートを与えるために、あなたがそのプロジェクトのProgram.csを見たいのなら、私はここに簡略化されたバージョンをアップロードしました。（かなり長いので、ここに投稿するべきではないと思いました。）

Answer 2

はい、AppDomainsを活用することはここで非常に理にかなっています。

最近、Windowsサービスを作り直して、さまざまなWCFサービスを独自のAppDomain内で動作するプラグインとしてロードしました。ブートストラッププロセスでMarshalByRefObjectオブジェクトを使用して動作を開始するケースがいくつかありますが、プラグインが読み込まれると、WCFを使用してAppDomain間の通信が非常に簡単になります。