21

When I am reading the file content from server it returns the following error message:

Caused by: java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:462)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:366)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:240)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:119)
at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:192)
at org.apache.coyote.Response.doWrite(Response.java:504)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383)
... 28 more

and my servlet program is

 response.setContentType("application/octet-stream");
 response.setHeader("Content-Disposition","attachment;filename="+filename);
 FileInputStream in = new FileInputStream(new File(filepath));
 ServletOutputStream output=response.getOutputStream();
 byte[] outputByte=new byte[4096];
 while(in.read(outputByte,0,4096)!=-1){
     output.write(outputByte,0,4096);//error indicates in this line
 }
 in.close();
 output.flush();
 output.close();

How to solve this issue?

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
Babu R
  • 1,025
  • 8
  • 20
  • 40
  • What is the client and how does it read the response if it is written by you? – Serge Oct 20 '12 at 08:15
  • Post the stack trace which indicates the error in line output.write(). Like Serge requested, please also post the client code if applicable. – Deepak Bala Oct 20 '12 at 08:40
  • I made a request to this servlet by jquery ajax function. – Babu R Oct 20 '12 at 08:42
  • I download a file in onclick() of div. – Babu R Oct 20 '12 at 08:42
  • @BabuR have you found a solution to this problem? I am struggling with the same problem while trying to transfer video through a servlet. – ishan Nov 11 '12 at 03:23
  • Read this for the complete explanation and possible resolution: http://stackoverflow.com/questions/30538640/javax-net-ssl-sslexception-read-error-ssl-0x9524b800-i-o-error-during-system?lq=1 – Devendra Vaja Jul 14 '15 at 18:23
  • Possible duplicate of [Official reasons for "Software caused connection abort: socket write error"](http://stackoverflow.com/questions/2126607/official-reasons-for-software-caused-connection-abort-socket-write-error) – kenorb Aug 25 '16 at 11:05

5 Answers5

14

I've got the same exception and in my case the problem was in a renegotiation procecess. In fact my client closed a connection when the server tried to change a cipher suite. After digging it appears that in the jdk 1.6 update 22 renegotiation process is disabled by default. If your security constraints can effort this, try to enable the unsecure renegotiation by setting the sun.security.ssl.allowUnsafeRenegotiation system property to true. Here is some information about the process:

Session renegotiation is a mechanism within the SSL protocol that allows the client or the server to trigger a new SSL handshake during an ongoing SSL communication. Renegotiation was initially designed as a mechanism to increase the security of an ongoing SSL channel, by triggering the renewal of the crypto keys used to secure that channel. However, this security measure isn't needed with modern cryptographic algorithms. Additionally, renegotiation can be used by a server to request a client certificate (in order to perform client authentication) when the client tries to access specific, protected resources on the server.

Additionally there is the excellent post about this issue in details and written in (IMHO) understandable language.

Dmitry
  • 3,028
  • 6
  • 44
  • 66
3

The socket has been closed by the client (browser).

A bug in your code:

byte[] outputByte=new byte[4096];
while(in.read(outputByte,0,4096)!=-1){
   output.write(outputByte,0,4096);
}

The last packet read, then write may have a length < 4096, so I suggest:

byte[] outputByte=new byte[4096];
int len;
while(( len = in.read(outputByte, 0, 4096 )) > 0 ) {
   output.write( outputByte, 0, len );
}

It's not your question, but it's my answer... ;-)

Aubin
  • 14,617
  • 9
  • 61
  • 84
  • 4
    While you are right about writing the correct length of bytes to the stream, this should not cause a 'Connection reset by peer' error. The client should just see some junk after the right data. – Deepak Bala Oct 20 '12 at 08:39
  • Thanks for your response. I tried with your code. but it shows java.lang.IndexOutOfBoundsException – Babu R Oct 20 '12 at 08:44
  • I solved the indexoutofbounds pbm. but the same problem what i asked is remain:\ – Babu R Oct 20 '12 at 08:53
  • 1
    java.net.SocketException: Connection reset by peer: socket write error at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:388) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:462) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:366) at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:413) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:401) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:91) – Babu R Oct 20 '12 at 08:53
0

The correct way to 'solve' it is to close the connection and forget about the client. The client has closed the connection while you where still writing to it, so he doesn't want to know you, so that's it, isn't it?

user207421
  • 305,947
  • 44
  • 307
  • 483
0

It seems like your problem may be arising at

while(in.read(outputByte,0,4096)!=-1){

where it might go into an infinite loop for not advancing the offset (which is 0 always in the call). Try

while(in.read(outputByte)!=-1){

which will by default try to read upto outputByte.length into the byte[]. This way you dont have to worry about the offset. See FileInputStrem's read method

prajeesh kumar
  • 1,916
  • 1
  • 17
  • 17
0

I had the same problem with small difference:

Exception was raised at the moment of flushing

It is a different stackoverflow issue. The brief explanation was a wrong response header setting:

response.setHeader("Content-Encoding", "gzip");

despite uncompressed response data content.

So the the connection was closed by the browser.

Community
  • 1
  • 1
Kayvan Tehrani
  • 3,070
  • 2
  • 32
  • 46