JAX-WS, zwei Services auf JBoss -> ClientAbortException , Broken Pipe

MadM

Mitglied
Hallo allerseits,

nach stundenlangem googeln ohne Ergebnis versuche ich mein Glück mal hier.

Folgendes Szenario:
JBoss 5.0.1 GA mit Java 1.6, JAX-WS 2.1.7

Es gibt 2 mit JAX-WS geschriebene Webservices, die in unserer Testumgebung friedlich nebeneinander laufen.

Beim Kunden jedoch, kommt es beim Start der zweiten Anwendung zu folgener Exception:

Code:
2010-11-25 07:03:52,074 INFO  [javax.enterprise.resource.webservices.jaxws.server.http] (HDScanner) WSSERVLET12: JAX-WS context listener initializing
...
2010-11-25 07:03:54,866 INFO  [javax.enterprise.resource.webservices.jaxws.servlet.http] (HDScanner) WSSERVLET14: JAX-WS servlet initializing
2010-11-25 07:03:55,049 SEVERE [javax.enterprise.resource.webservices.jaxws.servlet.http] (http-0.0.0.0-8080-1) caught throwable
java.io.IOException
	at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:278)
	at com.sun.xml.ws.transport.http.HttpAdapter.publishWSDL(HttpAdapter.java:539)
	at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:229)
	at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
	at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
	at com.sun.xml.ws.transport.http.servlet.WSServlet.doGet(WSServlet.java:82)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
	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.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
Caused by: com.ctc.wstx.exc.WstxIOException: null
	at com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:1687)
	at com.ctc.wstx.sw.BaseStreamWriter.close(BaseStreamWriter.java:288)
	at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:276)
	... 27 more
Caused by: ClientAbortException:  java.net.SocketException: Broken pipe
	at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:348)
	at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:314)
	at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:98)
	at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:99)
	at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
	at com.ctc.wstx.sw.BufferingXmlWriter.close(BufferingXmlWriter.java:194)
	at com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:1685)
	... 29 more
Caused by: java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:724)
	at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:449)
	at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:299)
	at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:950)
	at org.apache.coyote.Response.action(Response.java:186)
	at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:343)
	... 35 more


Laut meinen Erkentnissen kommt eine ClientAbortException dann zustande, wenn der Client die Verbindung abbricht, während der Server noch dabei ist, die Antwort zusammenzubauen.
Aber: Die Exception tritt bereits beim Start der Anwendung auf, zu diesem Zeitpunkt gibt es noch keine Clients! Was ist also die Ursache dieser Exception?

Bin für jeden Hinweis dankbar!

Gruß
Matthias
 
Nachtrag:

In der Theorie bin ich jetzt soweit:

Es gibt einen Client, der kontinuierlich Anfragen schickt. Diese Anfragen werden, während die Anwendung hochfährt, „gecached“, aber nicht beantwortet.
Wenn der Service dann da ist, werden die Anfragen abgearbeitet. Zu diesem Zeitpunkt hat der Client aber die Anfrage schon abgebrochen (da es ihm zu lange gedauert hat) und es kommt zu der Exception.

Die Frage ist nun: Was tun dagegen? Client runterfahren, wenn Anwendung neu gestartet wird?
Exception ignorieren und logs zumüllen lassen?
 
Hi Tom,

clientseitig tritt meines Wissens gar keine Exception auf....wobei...wenn ich recht überlege, muss ja irgend eine auftreten...
Das Problem ist, dass dieser Client nicht von uns ist und wir keinen Zugriff darauf haben.
Der Client holt sich, um die Dienstverfügbarkeit zu prüfen, 2-3 pro Sekunde die WSDL des Webservices (was ich für keine gute Idee halte).
Meine Theorie hat auch die recht pingelige Firewall nicht berücksichtig. Ich denke mittlerweile, dass die Firewall die Verbindungen wegen Inaktivität schliesst. Wenn der Service dann soweit ist, die Anfragen abzuarbeiten, ist die Verbindung zum Client schon geschlossen und es kommt zur Broken Pipe.

Gruß
Matthias
 
Zurück