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
    }
}