2

Delphi XE で記述された SOAP サーバー/クライアント アプリケーションは、企業のプロキシ/ファイアウォールの背後にある Windows 7 x64 でユーザーが実行するまで、しばらくの間正常に動作します。アプリケーションは、要求で TSOAPAttachment オブジェクトを送受信します。

問題：

  • このユーザーからの最初のリクエストが受信されて処理されると、サーバーはその後の (どのユーザーからの) リクエストも正常に処理できませんでした。
  • サーバーは引き続きリクエストに応答しますが、リクエストの SOAPAttachment は、このユーザーからの最初のリクエストの後に破損しているように見えます。これが、リクエストを正常に処理できなかった理由です。
  • サーバーにログをデバッグした後、リクエストのパラメーターの TSOAPAttachment.SourceStream がアクセス不能 (または空) になり、TSOAPAttachment.CacheFile も空になっていることに気付きました。したがって、SourceStream を使用しようとすると、アクセス違反エラーが返されます。
  • さらに調査したところ、最初のリクエストでtempフォルダに生成されたBorlandSoapAttachment(n)ファイルが残っており、ロックされており(リクエストが正常に完了すると削除されるはず)、次のリクエストのBorlandSoapAttachment(n+1)ファイルが山積みになっていることが判明しました。上。
  • IIS を再起動するか、アプリケーション プールをリサイクルすると、SOAP サーバーは再び機能します。
  • 同じマシンがこのネットワークの外で実行されている場合、問題なく動作するため、プロキシまたはユーザーのネットワークが原因であることは間違いありません。
  • 問題にさらに謎を追加するために、同じプロキシの背後にある WinXP でアプリケーションを実行してもまったく問題はありません。

この状況でしばらく立ち往生しているため、ヘルプや推奨事項は非常に高く評価されています。

よろしくお願いします。

4

2 に答える 2

1

添付ファイルを処理するすべてのサーバーロジックをデバッグして、Windows 7で特に失敗する可能性のあるコードを検出しようとしていることが本当に確実な場合は、次のことをお勧めします。

1）ネットワークスニファを使用するWiresharkはこのタスクに適しています。同じデータ/パラメータ値で2つの後続のリクエストを行い、HTTPコンテンツを比較します。この分析は、クライアント（データが常に同じコンテンツでクライアントマシンを離れているかどうかを確認するため）とサーバーの両方で実行して、受信データを分析する必要があります。

2）過去にも同じような状況に直面しましたが、問題を本当に理解しようとしてもうまくいきませんでした。ファイルをBase64でエンコードされた文字列パラメーターとして送信し、SOAP添付ファイルを使用しないという問題を回避しました。Base64を使用すると、送信するデータサイズが最大30％増加するという副作用があります。これは、大きなファイルを転送する場合に重要になる可能性があります。

SOAP添付ファイルはサーバーに一時ファイルを作成し、Windows7にはWindowsXPとは異なるファイルアクセスルールがあることに注意してください。これが最初の呼び出しが処理され、他の呼び出しが処理されていないことを説明できるかどうかはわかりませんが、ファイルアクセスに関連する何かがあるかもしれません。

于 2012-05-25T02:58:30.713 に答える
1

Win 7 での UAC (User Access Control) の問題かもしれません。win 7 でクライアントを「管理者として」実行してみて、正しく動作するかどうかを確認してください。

于 2012-05-25T13:17:39.243 に答える