2013-02-08 49 views
0

我已經將glassfish 3.1中的jax-ws web服務部署到了我的客戶端請求服務方法返回5000到10000個對象列表。在處理服務器之間拋出ClientTransportException和下面的堆棧跟蹤。Glassfish拋出com.sun.xml.ws.client.ClientTransportException:服務器發送HTTP狀態碼500:內部服務器錯誤

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名對象它的工作原理fine.But我沒有事情是size.It的事情是timeout.My請求連接的事情是創建性反應

打破之前請幫我

+0

沒有碼頭服務器 – MayurB

回答

0

你可以嘗試以下的任意組合:

  1. 當你的請求正在運行,從客戶端運行連續平。您應該看到在ping一臺破(或增加TTL至少確認理論)

  2. 設置以下JVM屬性的服務器和客戶端

    -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true 
    
  3. 之間的HTTP消息交換的轉儲

    嘗試TCPMon

  4. 執行JAX-WS SOAP Handler以捕獲管道乾燥時的確切時刻。當處理程序試圖登錄的消息,並得到由缺席留言燒燬

1

HTTP 500意味着內部服務器錯誤,這是您的客戶端沒有錯。有關您的請求的某些內容在服務器上失敗。你應該在那裏尋找更多的信息。你的客戶端堆棧跟蹤不會有幫助。

+0

上得到同樣的錯誤,我知道這是不在客戶端。但如何跟蹤服務器端的請求... – MayurB

+0

查看服務器日誌。你應該在那裏看到一個堆棧跟蹤。 –

+1

@ MayurB-對不起,我想我正在回答這個問題。歡迎您隨時關注客戶端堆棧跟蹤,但這不是問題所在。 –

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 
    } 
} 
相關問題