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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
Hi Chris, Thank you very much for your help. It appears that maxSwallowSize in the configuration has fixed the issue. Your help is greatly appreciated. Thank you, Bill -Original Message- From: Christopher Schultz [mailto:ch...@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$Jav
RE: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
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 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:ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
