You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bill Wolosek <bw...@kimobility.com> on 2015/12/03 16:27:02 UTC
Tomcat 8 JAX-WS javax.xml.ws.WebServiceException:
java.io.IOException: Error writing to server
We have recently updated the tech stack of a JAX-WS webservice running on JRE 1.7.0_17/Tomcat7.0.39 to JRE 1.8.0_66/Tomcat 8.0.28. The web app runs on Windows Server 2012. The web service uses a Metro implementation for JAX-WS. The clients run on various windows versions using JRE 7 and the JAX-WS client API built into the JRE. The webservice is used to upload files from the client machines to the webservice which saves them in a document management system. The implementation worked pretty much flawlessly under Java 7/Tomcat 7 but we have run into a problem with larger payloads (2MB or larger) running under Java 8/Tomcat 8 server side. The stack trace from the client is:
12/02/2015 14:12:38.699 [AWT-EventQueue-0] ERROR DocumentImporterMainWindow$SwingAction.importDocument: Unexpected Problem trying to call the CustomerOrderDMService
javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
at com.sun.proxy.$Proxy30.importDocument(Unknown Source)
at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.importDocument(DocumentImporterMainWindow.java:681)
at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.actionPerformed(DocumentImporterMainWindow.java:612)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.IOException: Error writing to server
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
... 54 more
Unfortunately nothing is logged server side in any of the tomcat logs. I have spent days searching for a solution to the problem without success. I have tried to debug the problem through various avenues such as logging the SOAP request/response client side and server side using the -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true (client) and -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true(server) java system properties but when the error occurs only the Client side request is being logged:
---[HTTP request - http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMService]---<http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMService%5d--->
Accept: text/xml, multipart/related
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.mycompany.com/CustomerOrderDMService/ImportDocument"
User-Agent: JAX-WS RI 2.2.9-b130926.1035 svn-revision#5f6196f2b90e9460065a4c2f4e30e065b245e51e
<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns3:ImportDocumentRequestDTO xmlns:ns3="http://www.mycompany.com/CustomerOrderDMService/" xmlns:ns2="http://www.mycompany.com/CustomerOrderDMService"><ns2:QuoteNumber>A000049</ns2:QuoteNumber><ns2:SerialNumber>STOCK</ns2:SerialNumber><ns2:DocumentType>Email</ns2:DocumentType><ns2:Description></ns2:Description><ns2:DocumentContents> **some base64 encoded byte[] of the file contents being uploaded**
Message has been truncated
use com.sun.xml.internal.ws.transport.http.HttpAdapter.dumpTreshold property to increase the amount of printed part of the message
--------------------
Since only the client side request is being logged we anticipate the server is not completely processing the request and it is falling into some kind of exception block, but without anything logging to the server log files we are having difficulties trouble shooting the problem.
We have tried using proxies such as the Monitoring built into Eclipse, but once again I only see the request from the client and no response from the server (when the client sends the larger requests that fail, small requests log request/response on both client and server). Other suggestions for debugging would be greatly appreciated.
We have also tried different combinations of Java and Tomcat:
* Tomcat 7/Java 7 = Works
* Tomcat 7/Java 8 = Works
* Tomcat 8/Java 7 = Doesn't Work
* Tomcat 8/Java 8 = Doesn't Work
This leads us to think that the issue is with Tomcat 8. Either something was changed in Tomcat 8 and we now need to set some new timeout/payload settings or Tomcat 8 has a bug related to this specific problem.
We have tried setting some of the Tomcat connector settings like maxPostSize="-1", connectionTimeout="-1", disableUploadTimeout="true", connectionUploadTimeout="-1", keepAliveTimeout="-1" but none of these worked and honestly feel like a shot in the dark without knowing what is going on server side.
We have tried updating the Metro jars server side to the most recent release (jaxws-ri-2.2.10) as well as running the client using Java 8. Unfortunately none of these worked. Any help would be greatly appreciated.
RE: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException:
java.io.IOException: Error writing to server
Posted by Bill Wolosek <bw...@kimobility.com>.
Hi Mark,
Your point of assuming Tomcat 7.0.39 = Tomcat 7 and Tomcat 8.0.28 = Tomcat 8 and not taking all other versions in-between into account was a bad on my part. Thanks for clarifying this for me.
It appears that maxSwallowSize in the <Connector> configuration has fixed the issue. I set it to -1 and now the service is working as expected. Now I just need to come up with a good maximum size value. Thank you very much for your help.
Thank you,
Bill
-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org]
Sent: Thursday, December 3, 2015 11:11 AM
To: Tomcat Users List
Subject: Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
On 03/12/2015 15:27, Bill Wolosek wrote:
> We have also tried different combinations of Java and Tomcat: *
> Tomcat 7/Java 7 = Works * Tomcat 7/Java 8 = Works *
> Tomcat 8/Java 7 = Doesn't Work * Tomcat 8/Java 8 = Doesn't
> Work
Assuming Tomcat 7 == 7.0.39 and Tomcat 8 == 8.0.28 the above list is somewhat misleading.
> This leads us to think that the issue is with Tomcat 8.
That conclusion is not supported by the evidence. 7.0.39 is over 2.5 years older than 8.0.28. What is far more likely is that you have been affected by one of the many fixes in that 2.5 year period that has been applied to both 7.0.x and 8.0.x.
> Either something was changed in Tomcat 8 and we now need to set some
> new timeout/payload settings or Tomcat 8 has a bug related to this
> specific problem.
See my previous comment.
> We have tried setting some of the Tomcat connector settings like
> maxPostSize="-1", connectionTimeout="-1", disableUploadTimeout="true",
> connectionUploadTimeout="-1", keepAliveTimeout="-1" but none of these
> worked and honestly feel like a shot in the dark without knowing what
> is going on server side.
The 2MB limit should have been a broad hint.
The stack trace on the client side could have been clearer but it is telling you that the server has dropped the connection.
Those two together plus a review of the changelog should have pointed you towards the maxSwallowSize of the HTTP connector.
You could have reduced the amount changelog to review by testing different Tomcat 7.0.x versions which should have pointed you towards
7.0.55 making the 2MB hint more obvious.
> We have tried updating the Metro jars server side to the most recent
> release (jaxws-ri-2.2.10) as well as running the client using Java 8.
> Unfortunately none of these worked. Any help would be greatly
> appreciated.
maxSwallowSize=-1 is the quick test to see if this is the issue. After that, you need to adjust it as appropriate for your environment since this was added to address CVE-2014-0230.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException:
java.io.IOException: Error writing to server
Posted by Mark Thomas <ma...@apache.org>.
On 03/12/2015 15:27, Bill Wolosek wrote:
> We have also tried different combinations of Java and Tomcat: *
> Tomcat 7/Java 7 = Works * Tomcat 7/Java 8 = Works *
> Tomcat 8/Java 7 = Doesn't Work * Tomcat 8/Java 8 = Doesn't
> Work
Assuming Tomcat 7 == 7.0.39 and Tomcat 8 == 8.0.28 the above list is
somewhat misleading.
> This leads us to think that the issue is with Tomcat 8.
That conclusion is not supported by the evidence. 7.0.39 is over 2.5
years older than 8.0.28. What is far more likely is that you have been
affected by one of the many fixes in that 2.5 year period that has been
applied to both 7.0.x and 8.0.x.
> Either something was changed in Tomcat 8 and we now need to set some
> new timeout/payload settings or Tomcat 8 has a bug related to this
> specific problem.
See my previous comment.
> We have tried setting some of the Tomcat connector settings like
> maxPostSize="-1", connectionTimeout="-1",
> disableUploadTimeout="true", connectionUploadTimeout="-1",
> keepAliveTimeout="-1" but none of these worked and honestly feel like
> a shot in the dark without knowing what is going on server side.
The 2MB limit should have been a broad hint.
The stack trace on the client side could have been clearer but it is
telling you that the server has dropped the connection.
Those two together plus a review of the changelog should have pointed
you towards the maxSwallowSize of the HTTP connector.
You could have reduced the amount changelog to review by testing
different Tomcat 7.0.x versions which should have pointed you towards
7.0.55 making the 2MB hint more obvious.
> We have tried updating the Metro jars server side to the most recent
> release (jaxws-ri-2.2.10) as well as running the client using Java 8.
> Unfortunately none of these worked. Any help would be greatly
> appreciated.
maxSwallowSize=-1 is the quick test to see if this is the issue. After
that, you need to adjust it as appropriate for your environment since
this was added to address CVE-2014-0230.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException:
java.io.IOException: Error writing to server
Posted by David kerber <dc...@verizon.net>.
On 12/3/2015 10:48 AM, Christopher Schultz wrote:
...
>> We have also tried different combinations of Java and Tomcat:
>> * Tomcat 7/Java 7 = Works
>> * Tomcat 7/Java 8 = Works
>> * Tomcat 8/Java 7 = Doesn't Work
>> * Tomcat 8/Java 8 = Doesn't Work
>>
>> This leads us to think that the issue is with Tomcat 8.
>
> Really? Java 7 + Tomcat 8 works, so... Tomcat 8 is the problem?
Take another look, Chris - you misread his table. Both entries with
Tomcat 8 fail, and both with Tomcat 7 succeed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException:
java.io.IOException: Error writing to server
Posted by Bill Wolosek <bw...@kimobility.com>.
Hi Chris,
Thank you very much for your help. It appears that maxSwallowSize in the <Connector> configuration has fixed the issue. Your help is greatly appreciated.
Thank you,
Bill
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Thursday, December 3, 2015 9:49 AM
To: Tomcat Users List
Subject: Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
Bill,
On 12/3/15 10:27 AM, Bill Wolosek wrote:
> We have recently updated the tech stack of a JAX-WS webservice running
> on JRE 1.7.0_17/Tomcat7.0.39 to JRE 1.8.0_66/Tomcat 8.0.28.
> The web app runs on Windows Server 2012. The web service uses a Metro
> implementation for JAX-WS. The clients run on various windows versions
> using JRE 7 and the JAX-WS client API built into the JRE.
> The webservice is used to upload files from the client machines to the
> webservice which saves them in a document management system. The
> implementation worked pretty much flawlessly under Java 7/Tomcat 7 but
> we have run into a problem with larger payloads (2MB or larger)
> running under Java 8/Tomcat 8 server side. The stack trace from the
> client is:
>
> 12/02/2015 14:12:38.699 [AWT-EventQueue-0] ERROR
> DocumentImporterMainWindow$SwingAction.importDocument: Unexpected
> Problem trying to call the CustomerOrderDMService
> javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
> at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source)
> at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
> at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
> at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
> at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
> at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
> at com.sun.proxy.$Proxy30.importDocument(Unknown Source)
> at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.importDocument(DocumentImporterMainWindow.java:681)
> at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.actionPerformed(DocumentImporterMainWindow.java:612)
> at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
> at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
> at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
> at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
> at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
> at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
> at java.awt.Component.processMouseEvent(Unknown Source)
> at javax.swing.JComponent.processMouseEvent(Unknown Source)
> at java.awt.Component.processEvent(Unknown Source)
> at java.awt.Container.processEvent(Unknown Source)
> at java.awt.Component.dispatchEventImpl(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
> at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
> at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Window.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
> at java.awt.EventQueue.access$500(Unknown Source)
> at java.awt.EventQueue$3.run(Unknown Source)
> at java.awt.EventQueue$3.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.awt.EventQueue$4.run(Unknown Source)
> at java.awt.EventQueue$4.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source) Caused by:
> java.io.IOException: Error writing to server
> at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at java.net.HttpURLConnection.getResponseCode(Unknown Source)
> ... 54 more
>
> Unfortunately nothing is logged server side in any of the tomcat logs.
> I have spent days searching for a solution to the problem without
> success. I have tried to debug the problem through various avenues
> such as logging the SOAP request/response client side and server side
> using the
> -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
> (client) and
> -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true(server) java
> system properties but when the error occurs only the Client side
> request is being logged:
>
> ---[HTTP request -
> http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMService]
> ---<http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMServ
> ice%5d--->
> Accept: text/xml, multipart/related
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://www.mycompany.com/CustomerOrderDMService/ImportDocument"
> User-Agent: JAX-WS RI 2.2.9-b130926.1035
> svn-revision#5f6196f2b90e9460065a4c2f4e30e065b245e51e
> <?xml version="1.0" ?><S:Envelope
> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns3:Impor
> tDocumentRequestDTO
> xmlns:ns3="http://www.mycompany.com/CustomerOrderDMService/"
> xmlns:ns2="http://www.mycompany.com/CustomerOrderDMService"><ns2:Quote
> Number>A000049</ns2:QuoteNumber><ns2:SerialNumber>STOCK</ns2:SerialNum
> ber><ns2:DocumentType>Email</ns2:DocumentType><ns2:Description></ns2:D
> escription><ns2:DocumentContents> **some base64 encoded byte[] of the
> file contents being uploaded**
>
> Message has been truncated
> use com.sun.xml.internal.ws.transport.http.HttpAdapter.dumpTreshold
> property to increase the amount of printed part of the message
> --------------------
>
> Since only the client side request is being logged we anticipate the
> server is not completely processing the request and it is falling into
> some kind of exception block, but without anything logging to the
> server log files we are having difficulties trouble shooting the
> problem.
>
> We have tried using proxies such as the Monitoring built into Eclipse,
> but once again I only see the request from the client and no response
> from the server (when the client sends the larger requests that fail,
> small requests log request/response on both client and server). Other
> suggestions for debugging would be greatly appreciated.
>
> We have also tried different combinations of Java and Tomcat:
> * Tomcat 7/Java 7 = Works
> * Tomcat 7/Java 8 = Works
> * Tomcat 8/Java 7 = Doesn't Work
> * Tomcat 8/Java 8 = Doesn't Work
>
> This leads us to think that the issue is with Tomcat 8.
Really? Java 7 + Tomcat 8 works, so... Tomcat 8 is the problem?
> Either something was changed in Tomcat 8 and we now need to set some
> new timeout/payload settings or Tomcat 8 has a bug related to this
> specific problem.
When you did the upgrade, what did you do with server.xml? Did you copy that file from the Tomcat 7 installation and drop it on top of the Tomcat 8 installation? Or did you start from the stock Tomcat 8 server.xml?
> We have tried setting some of the Tomcat connector settings like
> maxPostSize="-1", connectionTimeout="-1", disableUploadTimeout="true",
> connectionUploadTimeout="-1", keepAliveTimeout="-1" but none of these
> worked and honestly feel like a shot in the dark without knowing what
> is going on server side.
maxPostSize would have been the most obvious thing to use, as the default for that setting is 2MiB. Can you confirm that files slightly smaller than 2MiB succeed but slightly larger fail?
You might also want to look at maxSwallowSize in the <Connector> configuration.
Are you sure you have modified the correct <Connector>? If possible, post your server.xml file -- sanitized of all private information, of course.
> We have tried updating the Metro jars server side to the most recent
> release (jaxws-ri-2.2.10) as well as running the client using Java 8.
> Unfortunately none of these worked. Any help would be greatly appreciated.
Do you have the ability to attach a Filter to the web application? If so, try installing the FailedRequestFilter[1] to see if you can get some more information about what's going on.
While the FailedRequestFilter does not emit any logging information on the server side, it will return an HTTP response that is appropriate for the root cause of the error (e.g. "Entity Too Large" if the POSt body is too large for the configuration).
Are you able to get any information from the client side? Or just a stack trace? I suspect if Tomcat responds with a legitimate error message and HTTP response, your existing debugging settings will allow you to see what is going on. As of now, it looks like Tomcat is simply severing the connection.
-chris
[1]
http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Failed_Request_Filter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException:
java.io.IOException: Error writing to server
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Bill,
On 12/3/15 10:27 AM, Bill Wolosek wrote:
> We have recently updated the tech stack of a JAX-WS webservice
> running on JRE 1.7.0_17/Tomcat7.0.39 to JRE 1.8.0_66/Tomcat 8.0.28.
> The web app runs on Windows Server 2012. The web service uses a Metro
> implementation for JAX-WS. The clients run on various windows
> versions using JRE 7 and the JAX-WS client API built into the JRE.
> The webservice is used to upload files from the client machines to
> the webservice which saves them in a document management system. The
> implementation worked pretty much flawlessly under Java 7/Tomcat 7
> but we have run into a problem with larger payloads (2MB or larger)
> running under Java 8/Tomcat 8 server side. The stack trace from the
> client is:
>
> 12/02/2015 14:12:38.699 [AWT-EventQueue-0] ERROR DocumentImporterMainWindow$SwingAction.importDocument: Unexpected Problem trying to call the CustomerOrderDMService
> javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
> at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source)
> at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
> at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
> at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
> at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
> at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
> at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
> at com.sun.proxy.$Proxy30.importDocument(Unknown Source)
> at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.importDocument(DocumentImporterMainWindow.java:681)
> at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.actionPerformed(DocumentImporterMainWindow.java:612)
> at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
> at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
> at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
> at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
> at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
> at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
> at java.awt.Component.processMouseEvent(Unknown Source)
> at javax.swing.JComponent.processMouseEvent(Unknown Source)
> at java.awt.Component.processEvent(Unknown Source)
> at java.awt.Container.processEvent(Unknown Source)
> at java.awt.Component.dispatchEventImpl(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
> at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
> at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Window.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
> at java.awt.EventQueue.access$500(Unknown Source)
> at java.awt.EventQueue$3.run(Unknown Source)
> at java.awt.EventQueue$3.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.awt.EventQueue$4.run(Unknown Source)
> at java.awt.EventQueue$4.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source)
> Caused by: java.io.IOException: Error writing to server
> at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at java.net.HttpURLConnection.getResponseCode(Unknown Source)
> ... 54 more
>
> Unfortunately nothing is logged server side in any of the tomcat
> logs. I have spent days searching for a solution to the problem
> without success. I have tried to debug the problem through various
> avenues such as logging the SOAP request/response client side and
> server side using the
> -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
> (client) and
> -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true(server) java
> system properties but when the error occurs only the Client side
> request is being logged:
>
> ---[HTTP request - http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMService]---<http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMService%5d--->
> Accept: text/xml, multipart/related
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://www.mycompany.com/CustomerOrderDMService/ImportDocument"
> User-Agent: JAX-WS RI 2.2.9-b130926.1035 svn-revision#5f6196f2b90e9460065a4c2f4e30e065b245e51e
> <?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns3:ImportDocumentRequestDTO xmlns:ns3="http://www.mycompany.com/CustomerOrderDMService/" xmlns:ns2="http://www.mycompany.com/CustomerOrderDMService"><ns2:QuoteNumber>A000049</ns2:QuoteNumber><ns2:SerialNumber>STOCK</ns2:SerialNumber><ns2:DocumentType>Email</ns2:DocumentType><ns2:Description></ns2:Description><ns2:DocumentContents> **some base64 encoded byte[] of the file contents being uploaded**
>
> Message has been truncated
> use com.sun.xml.internal.ws.transport.http.HttpAdapter.dumpTreshold property to increase the amount of printed part of the message
> --------------------
>
> Since only the client side request is being logged we anticipate the
> server is not completely processing the request and it is falling
> into some kind of exception block, but without anything logging to
> the server log files we are having difficulties trouble shooting the
> problem.
>
> We have tried using proxies such as the Monitoring built into
> Eclipse, but once again I only see the request from the client and no
> response from the server (when the client sends the larger requests
> that fail, small requests log request/response on both client and
> server). Other suggestions for debugging would be greatly
> appreciated.
>
> We have also tried different combinations of Java and Tomcat:
> * Tomcat 7/Java 7 = Works
> * Tomcat 7/Java 8 = Works
> * Tomcat 8/Java 7 = Doesn't Work
> * Tomcat 8/Java 8 = Doesn't Work
>
> This leads us to think that the issue is with Tomcat 8.
Really? Java 7 + Tomcat 8 works, so... Tomcat 8 is the problem?
> Either something was changed in Tomcat 8 and we now need to set some
> new timeout/payload settings or Tomcat 8 has a bug related to this
> specific problem.
When you did the upgrade, what did you do with server.xml? Did you copy
that file from the Tomcat 7 installation and drop it on top of the
Tomcat 8 installation? Or did you start from the stock Tomcat 8 server.xml?
> We have tried setting some of the Tomcat connector settings like
> maxPostSize="-1", connectionTimeout="-1",
> disableUploadTimeout="true", connectionUploadTimeout="-1",
> keepAliveTimeout="-1" but none of these worked and honestly feel like
> a shot in the dark without knowing what is going on server side.
maxPostSize would have been the most obvious thing to use, as the
default for that setting is 2MiB. Can you confirm that files slightly
smaller than 2MiB succeed but slightly larger fail?
You might also want to look at maxSwallowSize in the <Connector>
configuration.
Are you sure you have modified the correct <Connector>? If possible,
post your server.xml file -- sanitized of all private information, of
course.
> We have tried updating the Metro jars server side to the most recent
> release (jaxws-ri-2.2.10) as well as running the client using Java 8.
> Unfortunately none of these worked. Any help would be greatly appreciated.
Do you have the ability to attach a Filter to the web application? If
so, try installing the FailedRequestFilter[1] to see if you can get some
more information about what's going on.
While the FailedRequestFilter does not emit any logging information on
the server side, it will return an HTTP response that is appropriate for
the root cause of the error (e.g. "Entity Too Large" if the POSt body is
too large for the configuration).
Are you able to get any information from the client side? Or just a
stack trace? I suspect if Tomcat responds with a legitimate error
message and HTTP response, your existing debugging settings will allow
you to see what is going on. As of now, it looks like Tomcat is simply
severing the connection.
-chris
[1]
http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Failed_Request_Filter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org