Glassfish拋出com.sun.xml.ws.client.ClientTransportException：服務器發送了HTTP狀態代碼500：內部服務器錯誤

Question

我已經將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個對象），則可以正常工作。但是我不認為這是大小問題。它是超時問題。我的請求連接在創建響應之前就斷開了

請幫我

Answer 1

HTTP 500表示內部服務器錯誤，這不是您的客戶端的錯誤。 有關您的請求的信息在服務器上失敗。 您應該在此處查找更多信息。 您的客戶端堆棧跟蹤將無濟於事。

Answer 2

您可以嘗試以下任意組合：

1. 在您的請求運行時，從客戶端運行連續ping。 您應該會發現ping中斷（或至少增加了TTL以確認理論）

2. 為服務器和客戶端之間的HTTP消息交換的轉儲設置以下JVM屬性

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

3. 試試TCPMon

4. 實現一個JAX-WS SOAP處理程序，以捕獲管道干了的確切時刻。 當處理程序嘗試記錄消息並被缺少的消息燒毀時，這可能具有拋出有意義的異常的額外好處。

Answer 3

如果未明確定義日志記錄策略，則服務器端可能會悄悄吞下您的異常。

我會嘗試添加一個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
    }
}