Quand "java. io. IOException: Réinitialisation de la connexion par le pair" est-il lancé?
ERROR GServerHandler - java.io.IOException: Connection reset by peer
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:323)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:202)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Ce journal provient d'un serveur de jeu implémenté à l'aide de netty. Qu'est-ce qui peut causer cette exception ?
6 answers
Java.io.IOException: Réinitialisation de la connexion par le pair
L'autre partie a brusquement interrompu la connexion au milieu d'une transaction. Cela peut avoir de nombreuses causes qui ne sont pas contrôlables du côté serveur. Par exemple, l'utilisateur final a décidé d'arrêter le client ou de changer le serveur brusquement tout en interagissant toujours avec votre serveur, ou le programme client s'est écrasé, ou la connexion Internet de l'utilisateur final est tombée en panne, ou la machine de l'utilisateur final s'est écrasée, etc., etc.
Pour développer la réponse de BalusC, tout scénario où l'expéditeur continue d'écrire après que le pair a cessé de lire et fermé son socket produira cette exception. En d'autres termes, une erreur de protocole d'application. Par exemple, si vous écrivez quelque chose à l'homologue que l'homologue ne comprend pas, puis qu'il ferme son socket en signe de protestation, et que vous continuez ensuite à écrire, la pile TCP de l'homologue émettra un RST, ce qui entraîne cette exception et ce message à l'expéditeur.
Java.io.IOException dans Netty signifie que votre serveur de jeu essaie d'envoyer des données à un client, mais que ce client a fermé la connexion à votre serveur.
Et cette exception n'est pas la seule! Il y en a plusieurs autres. Voir BadClientSilencer dans Xitrum. J'ai dû ajouter cela pour éviter que ces erreurs ne gâchent mon fichier journal.
Pour moi, le code utile qui m'aide était http://rox-xmlrpc.sourceforge.net/niotut/src/NioServer.java
// La télécommande a fermé de force la connexion, annuler
// la touche de sélection et fermer le canal.
private void read(SelectionKey key) throws IOException {
SocketChannel socketChannel = (SocketChannel) key.channel();
// Clear out our read buffer so it's ready for new data
this.readBuffer.clear();
// Attempt to read off the channel
int numRead;
try {
numRead = socketChannel.read(this.readBuffer);
} catch (IOException e) {
// The remote forcibly closed the connection, cancel
// the selection key and close the channel.
key.cancel();
socketChannel.close();
return;
}
if (numRead == -1) {
// Remote entity shut the socket down cleanly. Do the
// same from our end and cancel the channel.
key.channel().close();
key.cancel();
return;
}
...
Il y a beaucoup de facteurs , voyez d'abord si le serveur renvoie le résultat, puis vérifiez entre le serveur et le client.
Rectifiez-les d'abord côté serveur,puis vérifiez la condition d'écriture entre le serveur et le client !
Côté serveur rectifiez les délais d'attente entre le datalayer et le serveur du côté client rectifiez le délai d'attente et le nombre de connexions disponibles !
Je pense que cela devrait être java.net.SocketException car sa définition est indiquée pour une erreur TCP.
/**
* Thrown to indicate that there is an error in the underlying
* protocol, such as a TCP error.
*
* @author Jonathan Payne
* @version %I%, %G%
* @since JDK1.0
*/
public
class SocketException extends IOException {