javax.xml.ws.soap.SOAPFaultException Could not write bytes to socket

Dear All,

We are using Webservices to upload a large number of documents in Content Server 9.7.1. This is working pretty well but from time to time we have the following error: Could not write bytes to socket.

We do not understand why. If I restart the upload of the same document just after it works.

Do you have any idea what could be the cause of this weird error message?

Thanks,

Jean Philippe Forti
ECM Competence Center

Givaudan Schweiz AG - 5, Chemin de la Parfumerie - CH-1214 - Vernier - CH
T +4122431 8512 - F - http://www.givaudan.com

29 sept. 2011 10:33:03 [main] ERROR com.givaudan.opentext.client.OpentextUpload main - Internal Error
javax.xml.ws.soap.SOAPFaultException: Could not write bytes to socket
    at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:189)
    at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130)
    at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
    at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
    at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
    at $Proxy39.uploadContent(Unknown Source)
    at com.givaudan.opentext.client.OpentextUpload.uploadDocumentWS(OpentextUpload.java:289)
    at com.givaudan.opentext.client.OpentextUpload.runWSDomDocImport4GPAuditReports(OpentextUpload.java:195)
    at com.givaudan.opentext.client.OpentextUpload.main(OpentextUpload.java:123)
Caused by: javax.xml.ws.soap.SOAPFaultException: Could not write bytes to socket
    at com.opentext.livelink.service.core.ExceptionUtil.throwSOAPFaultException(ExceptionUtil.java:138)
    at com.opentext.livelink.service.core.ContentService_JAXWS.uploadContent(ContentService_JAXWS.java:80)
    at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246)
    at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
    at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
    at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
    at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
    at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
    at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
    at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
    at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
    at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:470)
    at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
    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.WSServletDelegate.doPost(WSServletDelegate.java:160)
    at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
    at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
    at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
    at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
    at java.lang.Thread.run(Unknown Source)

Find more posts tagged with

Comments

Kantish_Maitra

OpenText? Any Solution For this? Or a Hotfix perhaps?

Jean Philippe Forti

It still happens on CS10. The OpenText Support did not find the cause of our troubles.

Any other feedback. Out Java Architect keeps complaining about OpenText Webservices....

Kyle_Swidrovich

Salut Jean-Philippe,

Upload interruptions happening mid-stream are tricky to debug, especially with Java.

Java abstracts the raw socket communication and doesn’t log very detailed information about what error messages are coming directly from the OS.

Here are some thoughts off the top of my head:

<![if !supportLists]>1) <![endif]>Is the web service hosted on the same box as the Content Server instance?

If not, the machine will have to negotiate an open socket with the other machine.

If you do enough of these really quickly, you’ll exhaust the ephemeral ports.

<![if !supportLists]>2) <![endif]>Have you tried using something like Wireshark to capture raw traffic between the endpoints?

Examining the raw packet data could expose when and where the communication breakdown happens.

Cheers,

Kyle

Jean Philippe Forti

Hi Kyle,

Quoted Kyle Swidrovich on 02/15/2016 09:29 AM:

1) Is the web service hosted on the same box as the Content Server instance?

If not, the machine will have to negotiate an open socket with the other machine.

If you do enough of these really quickly, you’ll exhaust the ephemeral ports.

The java applications are not hosted on the Content Server Servers. But they are on the same data center.

Quoted Kyle Swidrovich on 02/15/2016 09:29 AM:

2) Have you tried using something like Wireshark to capture raw traffic between the endpoints?

Examining the raw packet data could expose when and where the communication breakdown happens.

We tried many things to analyse the error including deep wireshark analysis. As it occurs from time to time without any specific pattern, this is very tricky to solve.

We are opened to any suggestions.

Kyle_Swidrovich

If the web service is on a different machine than the Content Server instance, you’re likely running out of ephemeral ports.

Every request to that box is going to be opening a new socket connection, requiring a server side port to be allocated for that communication.

Those allocations will sit in a TIMED_WAIT state until they time out.

As long as they’re in a wait state, the OS won’t reuse them.

So if you hit the server with many independent requests in a short period of time, you’ll exhaust all available ephemeral ports, resulting in the failure to allocate new connections until one of the old ones times out.

This behaviour is something we saw back in the days of LAPI. It’s also not unique to Content Server.

There was an article written on this topic a while back that may also apply here:

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=56468157&objAction=ArticleView

Cheers,

Kyle

Jean Philippe Forti

Interesting, does it apply to Windows 2008?

Kyle_Swidrovich

The general concept applies to any OS implementing support for TCP/IP.