6

次の基本的なアーキテクチャのアプリがあります。

リモートアクセス（.NET Remoting）用に.NETタイプ（RemoteObject）を登録するWindowsサービス（Service）。RemoteObjectは、ThreadPoolを使用してIO処理を行う非ThreadPoolスレッドを作成します。ThreadPoolのサイズは、特定の理由で制限に制限する必要があります。GUIアプリは、.NETRemotingを使用してRemoteObjectにアクセスします。

ThreadPoolのサイズが小さすぎると、RemoteObjectを呼び出すときにGUIアプリがハングすることに気づきました。

私の質問は、これがハングしている理由と、RemoteObjectスレッドがThreadPoolの影響を受ける理由をどのように理解できるかということです。

これは私を夢中にさせています。ご協力ありがとうございました！

4

4 に答える 4

4

これが役立つかどうかはわかりませんが (これがあなたの問題かどうかはわかりません)、実行中のサービスをデバッグしたい場合は、コードでこれを平手打ちすることができます:

#if DEBUG
            if (!System.Diagnostics.Debugger.IsAttached)
                Debugger.Launch();
#endif

デバッガーの選択を求めるダイアログが表示されます。サービスの実行中のインスタンスにアタッチする簡単な方法です。これにより、UI がハングしているときに (デバッグ ツールバーの一時停止ボタンを押して) サービスに侵入し、スレッドとコールスタックをチェックアウトできます。

于 2008-11-06T19:06:06.553 に答える
4

.NET リモーティング インフラストラクチャは .NET ThreadPool を使用する (または基になるリソースを共有する) ことが判明したため、すべての ThreadPool スレッドがアプリで使用されている場合、リモーティング呼び出しがハングする可能性があります。

于 2009-09-21T14:13:39.997 に答える
2

これは非常に役に立たないかもしれませんが、とにかくそこに投げます.

リモート処理を介して通信するサービスとクライアントをデバッグするときは、通常、デバッガーの 2 つのインスタンスを実行します。1 つはクライアント用、もう 1 つはサービス用です。明確にするために、私は Visual Studio の 2 つのコピーを実行しています。サービスについては、attach コマンドを使用するか、main および call start を直接変更できます (すべてのサービス コードをバイパスします)。

メインを変更してデバッグを有効にする方法は次のとおりです。サービスへの DebugService 呼び出しが必要です。実際には、開始を呼び出すエントリ ポイントにすぎません。これを取得したらSERVICE_DEBUG、#if' !'. これで、基本的にサービスをコンソール アプリに変換できました。

#if SERVICE_DEBUG
            ServiceHost s = new ServiceHost();
            s.DebugService();
            Thread.Sleep( 300000000 );

#else
            ServiceBase.Run( ServicesToRun );
#endif

セットアップと実行の両方が完了したら、クライアントをステップ実行できます。リモート呼び出しがサービスにヒットすると、サービス コードをステップ実行できるため、両方を同時にデバッグできます。

好奇心から、リモート オブジェクトを GUI スレッドから直接呼び出していますか? その場合、リモート呼び出しが完了するまで、GUI スレッドはブロックされます。これにより、GUI 全体がロックされ、応答しなくなります。これは問題の解決策ではありませんが、そうであり、サービス スレッドが返されない場合は、GUI もハングします。

于 2008-11-06T18:41:44.450 に答える
1

数年前、私は.NETRemotingを使用する重要なビジネスシステムを設計および実装しました。クライアントはWindowsフォームGUIとして実装され、サーバーはWindowsサービスとして実装され、SQLServerデータベースがありました。

トラブルシューティング/デバッグ/開発用に設計したので、最初の設計基準の1つは、.NET Remotingの実装全体を簡単に削除して、デスクトップ上でシステム全体を実行できることでした。したがって、単一のブール構成設定を「false」=オフに変更することで、リモーティングを非アクティブ化できます。その後、.NET Remotingのオーバーヘッドや干渉なしに、トラブルシューティング、デバッグ、開発を完全に行うことができました。

これはあなたの状況にも役立つようです。実際のところ、特に実装が簡単なため、それが望ましい機能ではない状況を想像することはできません。

したがって、それを実装するために、構成設定は、クライアントとサーバーコードのそれぞれによって使用され、反対側との通信のためにインスタンス化する実装クラスを決定しました。すべての通信は、両側に2つの具体的な実装クラスを持つカスタムC＃インターフェイスを介して行われました。1つのクラスは.NET Remotingを使用して通信を実装し、もう1つのクラスは直接インプロセスパススルー（直接呼び出し）として通信を実装しました。

.NET Remotingについて何も知らなかったのは1組のクラス（両側に1つずつ）だけだったので、分離は完全でした。ほとんどの場合、すべての開発者はリモート処理をオフにして作業しました。これは、より高速で簡単です。必要なとき、まれに、オンにしました（ほとんどの場合、私だけ、または誰かがトラブルシューティングのためにテスト/本番環境に接続したとき）。

ちなみに、私はリモーティングインターフェイスを非常にシンプルにしました：public Response execute（Request）

それ以外にも、上記のデバッガーの起動のヒントを使用しました。GUIスレッドへの影響に注意する必要があることに同意します。

于 2008-11-07T01:42:56.287 に答える