Webcenter Content UCM-CS-000001 java.io.IOException: !csUnableToFinishReadingStreamWithLength

As I noticed in one of our UCM instances, for some time has been steadily increasing the count of exceptions:

<2013-02-15 10:33:40 CET> <Error> <oracle.ucm.idccs> <UCM-CS-000001> <wyjątek ogólny
java.io.IOException: !csUnableToFinishReadingStreamWithLength,
default/repo_ucm/ucm_cluster/weblayout/groups/public/documents/doc/mdaw/mde2/~edisp/016565.pdf,
696043,936043!csUnableToFinishedReadingBytesBeingWritten!$socket write error: Connection reset by peer.
 at intradoc.common.DataStreamWrapperUtils.copyInStreamToOutputStream(DataStreamWrapperUtils.java:126)
 at intradoc.server.ServiceHttpImplementor.sendStreamResponse(ServiceHttpImplementor.java:2296)
 at intradoc.server.Service.doResponse(Service.java:2081)
 at intradoc.server.FileService.doResponse(FileService.java:1469)
 at intradoc.server.ServiceRequestImplementor.doRequest(ServiceRequestImplementor.java:802)
 at intradoc.server.Service.doRequest(Service.java:1890)
 at intradoc.server.ServiceManager.processCommand(ServiceManager.java:435)
 at intradoc.server.IdcServerThread.processRequest(IdcServerThread.java:265)
 at intradoc.server.IdcServerThread.run(IdcServerThread.java:160)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: java.net.SocketException: socket write error: Connection reset by peer.
 at jrockit.net.SocketNativeIO.writeBytesPinned(Native Method)
 at jrockit.net.SocketNativeIO.socketWrite(SocketNativeIO.java:46)
 at java.net.SocketOutputStream.socketWrite0(SocketOutputStream.java)
 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
 at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
 at intradoc.common.DataStreamWrapperUtils.copyInStreamToOutputStream(DataStreamWrapperUtils.java:74)
 at intradoc.server.ServiceHttpImplementor.sendStreamResponse(ServiceHttpImplementor.java:2296)
 at intradoc.server.Service.doResponse(Service.java:2081)
 at intradoc.server.FileService.doResponse(FileService.java:1469)
 at intradoc.server.ServiceRequestImplementor.doRequest(ServiceRequestImplementor.java:802)
 at intradoc.server.Service.doRequest(Service.java:1890)
 at intradoc.server.ServiceManager.processCommand(ServiceManager.java:435)
 at intradoc.server.IdcServerThread.processRequest(IdcServerThread.java:265)
 at intradoc.server.IdcServerThread.run(IdcServerThread.java:160)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>

As I found with a small help of google above exception is a "typical" UCM broken pipe error, which is most often caused by the following:

• The network drops while the content server is attempting to communicate.
• The user cancels the request.
• The database is down or refuses a connection.

In the first reaction I thought:

In my cause it looks like TCP RST error when transferring data to the client application. The remote server can sent a RST packet to indicate an immediate dropping of the connection. This occurs when a packet is sent from UCM end of the connection but the other end does not recognize the connection. It will send back a packet with the RST bit set in order to forcibly close the connection. This can happen if the other side crashes and then comes back up, or if it calls close() on the socket while there is data from UCM in transit. Finally it is an indication that some of the data that are previously sent by UCM may not have been received.

After verifying the logs and code of my client applications I returned to start point of investigation. Client applications did not report any errors. There is also immposible that client side permemently drops connections.

I can't suspect network errors, cause client apps and UCM are running on the same physical machine.

Thereby I come up against a brick wall ...