クライアント側からリモート プロシージャル コールを行っていますが、コア ロジックにはサーバー側でのクエリの実行が含まれています。これは、IE8 を除くすべてのブラウザーで完全に機能します。コード 12152 のステータス コード例外が発生します。これをグーグルで調べたところ、セッションで何かを行う必要がある可能性があることがわかりましたが、現時点では適切な回答がありません。この問題にどのように対処すればよいですか?
2 に答える
返信ありがとうございます。幸いなことに、Fiddler などのツールを使用しなくても、問題の原因を突き止めることができました。
私の場合、IE8 の場合、RPC のロジックは必要な方法で実行されましたが、接続はシャットダウンされませんでした。そのため、ヘッダー情報とタイムアウト情報を受け入れることができる RequestBuilder オブジェクトで RpcRequestBuilder のインスタンスを使用する必要がありました。ヘッダーに「Connection : close」を入れて、RPC が通過したら接続が確実にシャットダウンされるようにしました。タイムアウト情報を設定すると、RequestTimeoutException オブジェクトを Throwable オブジェクトとして取得でき、それに基づいて、タイムアウトまたはその他の不適切なロジックが原因で RPC が失敗したかどうかを知ることができます。
あいまいなステータスコードは大丈夫です。いくつか見た後、すべてのものが指している
HTTP ステータス 12152 データベースまたはサーバーのメンテナンスのためにサーバーが一時的に停止されたか、ネットワーク エラーが発生しました。このステータスは通常、アップロードを試みるときに表示されます。後でもう一度やり直してください。
サーバー側とクライアント側でタイムアウトを増やしてみます。それが機能する場合は、別のプロキシを介してルーティングしてみてください。これにより、リクエストのヘッダーが破損する場合があります。プロキシまたは匿名の Web プロキシを介して実行している場合は、fiddler2 または wireshark をインストールし、リクエスト (主にヘッダー) を調べます。そこに何かファンキーなものがあるかもしれません。また、サーバー側でスニッフィングを試して、着信要求がどのように見えるかを確認する必要があります。
クライアント側で、開いているソケットをスニッフィングして、サーバーに対して開いているポートなどが混乱していないことを確認します。IEもこれについて不平を言う可能性があります。
残念ながら、指示していないように見えるエラーの1つです。
all get や post などを使用するなど、 requestbuilder で別のタイプまたはリクエストを使用することもできます。