我已将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,但它没有提供任何错误计数的正确理由。 已经在多次测试中观察到,我在客户端获得了客户端传输,但是在服务器上,方法线程单独工作到最后一行。它不知道连接断开。 我认为连接已断开,因此线程终于无法返回响应。
注意:如果返回响应很小,就像最多3000个对象一样工作正常。但我不认为这是大小问题。这是超时问题。我的请求连接在创建响应之前被打破
请帮帮我
答案 0 :(得分:1)
HTTP 500表示内部服务器错误,这不是您的客户端的错误。您的请求的某些内容在服务器上失败。你应该在那里寻找更多信息。您的客户端堆栈跟踪无济于事。
答案 1 :(得分:0)
您可以尝试以下任意组合:
当您的请求正在运行时,请从客户端运行连续ping。你应该看到ping的中断(或TTL的增加至少确认理论)
为服务器和客户端之间的HTTP消息交换转储设置以下JVM属性
-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true
尝试TCPMon
实现JAX-WS SOAP Handler以捕获管道干涸的确切时刻。当处理程序尝试记录消息并被缺席消息烧毁时,这可能会带来额外的好处:
答案 2 :(得分: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
}
}