0

jax-ws Web サービスを Glassfish 3.1 にデプロイしました。オブジェクトの 5000 から 10000 のリストを返すサービス メソッドに対するクライアント要求です。処理サーバーの間に、次のスタック トレースで ClientTransportException がスローされます。

com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status code 500: Internal Server Error
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:314)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:265)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:184)
at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:109)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.client.Stub.process(Stub.java:323)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:113)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
at $Proxy190.webservicemethodcall(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Glassfish リクエストを監視しようとしましたが、リクエスト統計に errorcount 1 が表示されましたが、errorcount の適切な理由がわかりません。複数のテストで観察されましたが、クライアントではクライアントトランスポートを取得しましたが、サーバーではメソッドスレッドが最後の行まで個別に適切に機能しています.切断された接続を認識していません. 接続が切れて、スレッドがついに応答を返すことができないと思います。

注：リターンレスポンスが3000オブジェクトまでのように小さい場合は正常に動作します.しかし、サイズの問題ではありません.タイムアウトの問題です.レスポンスを作成する前にリクエスト接続が切断されます

私を助けてください

4

3 に答える 3

1

HTTP 500は、クライアントの障害ではない内部サーバーエラーを意味します。リクエストに関する何かがサーバーで失敗しています。あなたはより多くの情報のためにそこを探すべきです。クライアント側のスタックトレースは役に立ちません。

于 2013-02-08T05:32:41.433 に答える
0

ロギング ポリシーが明確に定義されていない場合、例外がサーバー側で黙って飲み込まれる可能性があります。

これがどこで発生したかを検出するために、try/catch ブロックを追加しようとします (ログ戦略を改善する場合は、後で削除します)。

public returnType yourMethod(){
    try {
    .... all your code
    }catch (final Throwable t) {
      log.error("Failed to wait for device update: " + t.getMessage());
      //eventually re-throw the error
    }
}
于 2013-02-11T10:38:46.277 に答える
0

次の任意の組み合わせを試すことができます。

  1. リクエストの実行中に、クライアントから継続的に ping を実行します。ping の中断が見られるはずです (または少なくとも理論を確認するために TTL の増加)。

  2. サーバーとクライアント間の HTTP メッセージ交換のダンプ用に、次の JVM プロパティを設定します。

    -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true

  3. TCPMon を試す

  4. JAX-WS SOAP ハンドラーを実装して、パイプが空になった正確な瞬間をキャプチャします。これには、ハンドラーがメッセージをログに記録しようとしたときに意味のある例外をスローするという追加の利点があり、存在しないメッセージによって焼失する可能性があります。

于 2013-02-08T14:16:19.450 に答える