0

この質問は、SoapHttpClientProtocol がスレッドセーフではないことを示しているためです。そして、私の実際のテストでは、私の SoapHeader プロパティが呼び出し間で混乱し続けているため、これが真実であることがわかりました。これをスレッド間で使用し、プロパティを正しく保つことができるようにする方法はありますか? そして、別のスレッドが接続を閉じたときに、あるスレッドが接続が開いていると考えているという質問で与えられた例に遭遇しないようにしてください。リクエストが行われた後、soap ヘッダーの値について心配する必要はありますか? リクエストが発行されるまで、プロパティが設定どおりであることを確認するにはどうすればよいですか?

4

1 に答える 1

1

私が最初に尋ねることは、マルチスレッドにしない場合、サービスが正しく動作するかということです。後続の呼び出しを行った場合、それらはすべて正しく機能し、目的の結果が得られますか? そうでない場合は、サーバー側に問題がある可能性が高くなります。

何を送信しているかを確認するには、soap メッセージを送信する前にシリアル化できます。正しく生成されていることを確認してください。

私の仕事は多くの Web サイトへのアクセスをブロックしますが、私の記憶が正しければ、CodeProject にはいくつかの例があります。

シングル スレッドが機能する場合は、シリアライゼーション レイヤーを配置し、マルチスレッド シナリオでファイルをディスクに書き込みます。次に、コードが送信していると考えているものによって、何が機能していて何が機能していないかを確認できます。

エンドポイントが NAT ファイアウォールの背後にあるように、エンドポイントを 1 つの値として認識している可能性がある一方で、複数の接続を確立しようとしているため、サーバーによって呼び出しが混在している可能性が高くなります。つまり、接続を取得している可能性がありますが、他のスレッドの 1 つが最初にメッセージを取得します。その場合は、各スレッドを独自のアプリ ドメインでスピンアップしてみて、何か効果があるかどうかを確認してください。それがうまくいくと言っているわけではありませんが、他に何を試すことができるかは頭の中でわかりません.

于 2009-12-23T17:07:21.217 に答える