javax.xml.ws.WebServiceException: java.io.IOException: Błąd zapisu na serwerze Tomcat 8

Question

Niedawno zaktualizowaliśmy stos technologii usługi WWW JAX-WS działającej w środowisku JRE 1.7.0_17/Tomcat7.0.39 do wersji JRE 1.8. 0_66/Tomcat 8.0.28. Aplikacja internetowa działa w systemie Windows Server 2012. Usługa internetowa korzysta z implementacji Metro dla JAX-WS. Klienci działają na różnych wersjach systemu Windows przy użyciu środowiska JRE 7 i interfejsu API klienta JAX-WS wbudowanego w środowisko JRE. Usługa sieciowa służy do przesyłania plików z komputerów klienckich do usługi internetowej, która zapisuje je w systemie zarządzania dokumentami. Implementacja przebiegła bezbłędnie w środowisku Java 7/Tomcat 7, ale pojawił się problem z większymi ładunkami (2 MB lub więcej) działającymi pod kontrolą serwera Java 8/Tomcat 8. Ślad stosu od klienta to:

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 

Niestety nic nie jest rejestrowane po stronie serwera w żadnym z tomcat logów. Długo szukałem rozwiązania problemu bez powodzenia. Próbowałem rozwiązać problem za pomocą różnych sposobów, takich jak rejestrowanie strony żądania/odpowiedzi protokołu SOAP i po stronie serwera przy użyciu właściwości systemu java -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true (klient) i -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true (serwer), ale gdy wystąpi błąd, tylko żądanie strony klienta jest są rejestrowane:

---[HTTP request - http://localhost:8080/CustomerOrderDM/services/CustomerOrderDMService]--- 
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 
-------------------- 

Ponieważ tylko wniosek po stronie klienta jest zalogowany przewidujemy serwer nie jest całkowicie przetwarzania żądania i wpada do jakiegoś bloku wyjątków, ale bez niczego rejestrowanie w plikach dziennika serwera my mają trudności z rozwiązaniem problemu.

Próbowaliśmy korzystać z serwerów proxy, takich jak Monitorowanie wbudowane w Eclipse, ale ponownie widzę tylko żądanie od klienta i brak odpowiedzi z serwera (gdy klient wysyła większe żądania, które zawiodły, małe żądanie żądania dziennika/odpowiedź na klienta i serwer). Inne sugestie dotyczące debugowania będą bardzo mile widziane.

Mamy również próbowałem różnych kombinacji Java i Tomcat:

• Tomcat 7/Java 7 = Działa
• Tomcat 7/8 = Java działa
• Tomcat 8/Java 7 = Nie pracować
• Tomcat 8/8 = Java nie działa

to prowadzi nas do myślenia, że ​​problem jest z Tomcat 8. Każda ze coś zostało zmienione w Tomca t 8 i musimy teraz ustawić kilka nowych ustawień timeout/payload lub Tomcat 8 ma błąd związany z tym konkretnym problemem.

Staraliśmy ustawienie niektóre ustawienia złącza Tomcat jak maxPostSize="-1", connectionTimeout="-1", disableUploadTimeout="true", connectionUploadTimeout="-1", keepAliveTimeout="-1" ale żaden z nich nie pracował uczciwie i poczuć się jak strzał w ciemno nie wiedząc, co się dzieje po stronie serwera.

Próbowaliśmy aktualizacji strony serwera słoików Metro do najnowszej wersji (jaxws-ri-2.2.10), a także do uruchamiania klienta przy użyciu Javy 8. Niestety, żaden z nich nie zadziałał. Każda pomoc będzie bardzo ceniona.

Answer 1

Okazuje się, że Tomcat 7.0.55 zawarte Fix:

CVE-2014-0230: 
Add a new limit, defaulting to 2MB, for the amount of data Tomcat will swallow for an aborted upload. The limit is configurable by maxSwallowSize attribute of an HTTP connector. 

moich problemów został rozwiązany przez ustawienie maxSwallowSize = "- 1" ustawienie konfiguracji <Connector> w serwerach tomcat serwer .xml.

Chciałbym podziękować Mark Thomas i Chris Schultz z listy mailingowej użytkowników Tomcat za ich pomoc. Aby uzyskać instrukcje dotyczące dołączania do listy adresowej, kliknij opcję here. Chciałbym również podziękować Vinayakowi za wskazanie mi wsparcia Tomcat.

Answer 2

Wygląda na to, że jest to więcej błędów związanych z Tomcat. Opublikuj problem zespołowi Tomcat.

http://tomcat.apache.org/bugreport.html