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 请求，但它在请求统计信息中显示错误计数 1，但它没有为我提供错误计数的任何适当原因。在多次测试中已经观察到，我在客户端获得了客户端传输，但在服务器上，方法线程分别正常工作到最后一行。它不知道连接断开。我认为连接已断开，因此线程最终无法返回响应。

注意：如果返回响应很小，例如最多 3000 个对象，它可以正常工作。但我不认为这是大小问题。这是超时问题。我的请求连接在创建响应之前中断

请帮我

4

3 回答 3

1

HTTP 500 表示内部服务器错误，这不是您的客户端的错。您的请求在服务器上失败。你应该在那里寻找更多信息。您的客户端堆栈跟踪不会有帮助。

于 2013-02-08T05:32:41.433 回答
0

您可以尝试以下任意组合：

  1. 在您的请求运行时，从客户端运行连续 ping。您应该看到 ping 中断（或至少 TTL 增加以确认理论）

  2. 为服务器和客户端之间的 HTTP 消息交换的转储设置以下 JVM 属性

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

  3. 试试TCPMon

  4. Implement a JAX-WS SOAP Handler to capture the exact moment when the pipe runs dry. This might have the extra benefit of throwing a meaningful exception when the handler attempts to log a message and gets burnt by the absent message

于 2013-02-08T14:16:19.450 回答
0

If your logging policy is not clearly defined, your exception might be silently swallowed on server side.

I would try to add a try/catch block to detect where this happens (and eventually remove it later if you improve your logging strategy)

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 回答