I have a tomcat6 server with axis2, that provides web services. This server get connections through an apache2 server using mod_jk. Most connections are ok, but sometimes I get exceptions like this one:
17:17:23,730 ERROR RPCMessageReceiver:160 - com.ctc.wstx.exc.WstxEOFException: Unexpected EOF; was expecting a close tag for element <ns2:dhAudioFile>
at [row,col {unknown-source}]: [1,4097]
I am really lost here. The exceptions are being thrown from tomcat, but I don't know in which point the message is getting cut, and don't know which server configuration I should check, nor which parameters.
Here is the whole stack trace, if it can be of any help:
17:17:23,730 ERROR RPCMessageReceiver:160 - com.ctc.wstx.exc.WstxEOFException: Unexpected EOF; was expecting a close tag for element <ns2:dhAudioFile>
at [row,col {unknown-source}]: [1,4097]
org.apache.axiom.om.OMException: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF; was expecting a close tag for element <ns2:dhAudioFile>
at [row,col {unknown-source}]: [1,4097]
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:293)
at org.apache.axiom.om.impl.llom.OMElementImpl.getNextOMSibling(OMElementImpl.java:337)
at org.apache.axiom.om.impl.traverse.OMChildrenIterator.next(OMChildrenIterator.java:102)
at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:553)
at org.apache.axis2.rpc.receivers.RPCUtil.processRequest(RPCUtil.java:153)
at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:188)
at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:662)
EDIT:
In response to a question asked in the comments, here are other column values found on the logs:
[1,10930] x 3
[1,5465] x 15
[1,1380] x 3
[1,2736] x 24
[1,34144] x 3
[1,4097] x 9
[1,1368] x 3
POSTrequest (or another type - but one that's sending a request body of significant size) from a client of the web service, correct? Column 4097 is significant, and is probably a pointer to the root cause; 4096 is 4 kilobytes. Can you do some testing and confirm that request bodies are all truncating after 4 KB? I'm tempted to point the accusatory finger at mod_jk, but let's confirm first. – Shane Madden Feb 22 '12 at 17:06