Comment résoudre "réinitialisation de la connexion par peer: erreur d'écriture de socket"?
lorsque je lis le contenu du fichier depuis le serveur, il renvoie le message d'erreur suivant:
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
et mon programme de servlet est
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();
Comment résoudre ce problème?
5 réponses
j'ai la même exception et dans mon cas le problème était dans un processus de renégociation. En fait, mon client a fermé une connexion quand le serveur a essayé de changer une suite de chiffrement. Après avoir creusé, il apparaît que dans le JDK 1.6 update 22 le processus de renégociation est désactivé par défaut . Si vos contraintes de sécurité le permettent, essayez d'activer la renégociation non sécurisée en paramétrant la propriété du système sun.security.ssl.allowUnsafeRenegotiation à true . Voici quelques informations sur l' le processus:
renégociation de Session est un mécanisme dans le protocole SSL qui permet au client ou au serveur de déclencher une nouvelle poignée de main SSL pendant une communication SSL en cours. La renégociation a été initialement conçu comme un mécanisme pour augmenter la sécurité d'un canal SSL en cours, par déclenchant le renouvellement des clés crypto utilisées pour sécuriser ce canal. Toutefois, cette mesure de sécurité n'est pas nécessaire avec cryptographiques modernes algorithme. De plus, la renégociation peut être utilisée par un serveur pour demander un certificat client (afin d'effectuer le client authentification) lorsque le client tente d'accéder à des, protégé des ressources sur le serveur.
en outre, il ya le excellent post à propos de cette question en détail et écrit dans (IMHO) langage compréhensible.
la prise a été fermée par le client (navigateur).
un bug dans votre code:
byte[] outputByte=new byte[4096];
while(in.read(outputByte,0,4096)!=-1){
output.write(outputByte,0,4096);
}
le dernier paquet lu, puis écrit peut avoir une longueur < 4096, donc je suggère:
byte[] outputByte=new byte[4096];
int len;
while(( len = in.read(outputByte, 0, 4096 )) > 0 ) {
output.write( outputByte, 0, len );
}
Ce n'est pas votre question, mais c'est ma réponse... ;- )
la bonne façon de "résoudre" est de fermer la connexion et d'oublier le client. Le client a fermé la connexion pendant que vous lui écrivez encore, donc il ne veut pas vous connaître, alors c'est tout, n'est-ce pas?
il semble que votre problème puisse apparaître à
while(in.read(outputByte,0,4096)!=-1){
où il peut aller dans une boucle infinie pour ne pas avancer l'offset (0 toujours dans l'appel). Essayez
while(in.read(outputByte)!=-1){
qui tentera par défaut de lire upto outputByte.longueur dans le byte[] . De cette façon, vous n'avez pas à vous soucier de l'offset. Voir FileInputStrem de la méthode de lecture
j'ai eu le même problème avec une petite différence:
Exception a été soulevée au moment de rinçage
C'est un autre stackoverflow question . La brève explication était un mauvais réglage de l'en-tête de réponse:
réponse.setHeader ("Content-Encoding"," gzip");
malgré un contenu de données de réponse non compressé.
ainsi le le connexion a été fermée par le navigateur.