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?
asked Oct 20, 2012 at 8:03
7
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.
answered Jul 15, 2013 at 14:15
DmitryDmitry
3,0285 gold badges44 silver badges65 bronze badges
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… 
answered Oct 20, 2012 at 8:10
AubinAubin
14.5k9 gold badges62 silver badges84 bronze badges
4
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?
answered Oct 20, 2012 at 9:11
2
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
answered Oct 20, 2012 at 9:27
prajeesh kumarprajeesh kumar
1,8961 gold badge17 silver badges17 bronze badges
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.
answered May 2, 2016 at 14:24
Kayvan TehraniKayvan Tehrani
2,9702 gold badges31 silver badges45 bronze badges
Программа успешно годами парсила стату с Liveinternet до начала этой недели. С этой недели как бабка отшептала, выдает ошибку «Socket error 10054. Connection reset by peer.»
Сначала я думал что проблемы с авторизацией, сниффил то что при авторизации передаёт браузер, пытался имитировать те же настройки при передаче запроса POST, но позже я понял что и простой GET главной страницы не работает
Для простого теста я создал пустое приложение, бросил на форму idHttp, TIdSSLIOHandlerSocketOpenSSL (соединил их), кинул файлы в debug — libeay32.dll, ssleay32.dll, вставил код:
| Delphi | ||
|
при выполнении выдаётся исключение «Socket error 10054. Connection reset by peer.»
Что я пробовал:
— запускать на разных пк, с разных провайдеров
— менять настройки useragent
— Менял также другие настройки request, но не уверен что правильно
Может быть liveinternet настроил защиту от ботов, но мне кажется что это объясняется банальней
Буду благодарен если вы попробуете у себя повторить мои действия и разобраться
P.s. Delphi XE8, инди версия хз
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
Connection Reset by peer means the remote side is terminating the session. This error is generated when the OS receives notification of TCP Reset (RST) from the remote peer.
Understanding Connection Reset by peer
Connection reset by peer means the TCP stream was abnormally closed from the other end. A TCP RST was received and the connection is now closed. This occurs when a packet is sent from our 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.
“Connection reset by peer” is the TCP/IP equivalent of slamming the phone back on the hook. It’s more polite than merely not replying, leaving one hanging. But it’s not the FIN-ACK expected of the truly polite TCP/IP.
Understanding RST TCP Flag
RST is used to abort connections. It is very useful to troubleshoot a network connection problem.
RST (Reset the connection). Indicates that the connection is being aborted. For active connections, a node sends a TCP segment with the RST flag in response to a TCP segment received on the connection that is incorrect, causing the connection to fail.
The sending of an RST segment for an active connection forcibly terminates the connection, causing data stored in send and receive buffers or in transit to be lost. For TCP connections being established, a node sends an RST segment in response to a connection establishment request to deny the connection attempt. The sender will get Connection Reset by peer error.
Understanding TCP Flags SYN ACK RST FIN URG PSH
Check network connectivity
The “ping” command is a tool used to test the availability of a network resource. The “ping” command sends a series of packets to a network resource and then measures the amount of time it takes for the packets to return.
If you want to ping a remote server, you can use the following command: ping <remote server>
In this example, “<remote server>” is the IP address or hostname of the remote server that you want to ping.
Ping the remote host we were connected to. If it doesn’t respond, it might be offline or there might be a network problem along the way. If it does respond, this problem might have been a transient one (so we can reconnect now)
If you are experiencing packet loss when pinging a remote server, there are a few things that you can do to troubleshoot the issue.
The first thing that you can do is check the network interface on the remote server. To do this, use the “ifconfig” command. The output of the “ifconfig” command will show you the status of all network interfaces on the system. If there is a problem with one of the interfaces, it will be shown in the output.
You can also use the “ip route” command to check routing information. The output of the “ip route” command will show you a list of all routes on the system. If there is a problem with one of the routes, it will be shown in the output.
If you are still experiencing packet loss, you can try to use a different network interface. To do this, use the “ping” command with the “-i” option. For example, the following command will use the eth0 interface:
ping -i eth0 google.com
Check remote service port is open
A port is a logical entity which acts as a endpoint of communication associated with an application or process on an Linux operating system. We can use some Linux commands to check remote port status.
Commands like nc, curl can be used to check if remote ports are open or not. For example, the following command will check if port 80 is open on google.com:
nc -zv google.com 80
The output of the above command should look something like this: Connection to google.com port 80 [tcp/80] succeeded!
This means that the port is open and we can establish a connection to it.
6 ways to Check a remote port is open in Linux
Check application log on remote server
For example, if the error is related with SSH. we can debug this on the remote server from sshd logs. The log entries will be in one of the files in the /var/log directory. SSHD will be logging something every time it drops our session.
Oct 22 12:09:10 server internal-sftp[4929]: session closed for local user fred from [192.0.2.33]
Check related Linux kernel parameters
Kernel parameter is also related to Connection Reset by peer error. The keepalive concept is very simple: when we set up a TCP connection, we associate a set of timers. Some of these timers deal with the keepalive procedure. When the keepalive timer reaches zero, we send our peer a keepalive probe packet with no data in it and the ACK flag turned on.
we can do this because of the TCP/IP specifications, as a sort of duplicate ACK, and the remote endpoint will have no arguments, as TCP is a stream-oriented protocol. On the other hand, we will receive a reply from the remote host (which doesn’t need to support keepalive at all, just TCP/IP), with no data and the ACK set.
If we receive a reply to we keepalive probe, we can assert that the connection is still up and running without worrying about the user-level implementation. In fact, TCP permits us to handle a stream, not packets, and so a zero-length data packet is not dangerous for the user program.
we usually use tcp keepalive for two tasks:
- Checking for dead peers
- Preventing disconnection due to network inactivity
Check Application heartbeat configuration
Connection Reset by peer error is also related to the application. Certain networking tools (HAproxy, AWS ELB) and equipment (hardware load balancers) may terminate “idle” TCP connections when there is no activity on them for a certain period of time. Most of the time it is not desirable.
We will use rabbitmq as an example. When heartbeats are enabled on a connection, it results in periodic light network traffic. Therefore heartbeats have a side effect of guarding client connections that can go idle for periods of time against premature closure by proxies and load balancers.
With a heartbeat timeout of 30 seconds the connection will produce periodic network traffic roughly every 15 seconds. Activity in the 5 to 15 second range is enough to satisfy the defaults of most popular proxies and load balancers. Also see the section on low timeouts and false positives above.
Check OS metric on peer side
Connection Reset by peer can be triggered by a busy system. we can setup a monitoring for our Linux system to the metrics like CPU, memory, network etc. If the system is too busy, the network will be impacted by this.
For example, we can use the “top” command to check the CPU usage. The output of the “top” command will show us the list of processes sorted by CPU usage. If there is a process which is using a lot of CPU, we can investigate this further to see if it is causing the network issues.
We can also use the “netstat” command to check network statistics. The output of the “netstat” command will show us a list of active network connections. If there are too many connections established, this could be causing the network issues.
We can use these commands to troubleshoot network issues on a Linux system. By using these commands, we can narrow down the root cause of the issue and fix it.
Monitoring Linux System with Telegraf Influxdb Grafana
Troubleshoot Network Slow Problems In Linux
Sorry, I forgot to provide the full traceback. Here is the traceback I get when I get the error. Also, I’m not understanding how to use the HTTP proxy and why that would make a difference when it works from the command line with curl.
Traceback (most recent call last):
File "/Users/oconnor/.virtualenvs/emails/bin/django-admin.py", line 5, in <module>
management.execute_from_command_line()
File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/__init__.py", line 429, in execute_from_command_line
utility.execute()
File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
output = self.handle(*args, **options)
File "/Users/oconnor/Sites/wenworld/emails/emails/management/commands/ww_daily_headlines_send.py", line 114, in handle
self.add_newsletter_to_sendgrid(sendgrid_newsletter_name, NEWSLETTER_SLUG)
File "/Users/oconnor/Sites/wenworld/emails/emails/management/commands/ww_daily_headlines_send.py", line 94, in add_newsletter_to_sendgrid
html=email.html
File "/Users/oconnor/.virtualenvs/emails/src/sendgrid/src/sendgrid/__init__.py", line 67, in newsletter_add
subject=subject, text=text, html=html)
File "/Users/oconnor/.virtualenvs/emails/src/sendgrid/src/sendgrid/__init__.py", line 157, in get
return self.call(method, **kwargs)
File "/Users/oconnor/.virtualenvs/emails/src/sendgrid/src/sendgrid/__init__.py", line 56, in call
result_json = json.loads(response.content)
File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/requests/models.py", line 429, in __getattr__
self._content = self.read()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 351, in read
data = self._sock.recv(rbufsize)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 553, in read
s = self.fp.read(amt)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1276, in read
return s + self._file.read(amt - len(s))
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 380, in read
data = self._sock.recv(left)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 219, in recv
return self.read(buflen)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 138, in read
return self._sslobj.read(len)
socket.error: [Errno 54] Connection reset by peer