SQLRecoverableException: Exception d'E/S: Réinitialisation de la connexion

L'erreur se produit sur certaines distributions RedHat. La seule chose que vous devez faire est d'exécuter votre application avec le paramètre java.sécurité.egd=file:///dev/urandom:

java -Djava.security.egd=file:///dev/urandom [your command]

Nous avons connu ces erreurs par intermittence après la mise à niveau de 11g à 12c et notre java était sur 1.6.

Le correctif pour nous était de mettre à niveau java et jdbc de 6 à 7

export JAVA_HOME='/usr/java1.7'

export CLASSPATH=/u01/app/oracle/product/12.1.0/dbhome_1/jdbc/libojdbc7.jar:$CLASSPATH 

Plusieurs jours plus tard, la connexion est toujours intermittente.

Nous avons fini par supprimer tous les java 7 ci-dessus. Java 6 était bien. Le problème a été résolu en ajoutant ceci à notre utilisateur bash_profile.

Nos scripts groovy qui rencontraient l'erreur utilisaient /dev/random sur notre serveur de machine virtuelle par lots. Ci-dessous forcé java et groovy à utiliser /dev/urandom.

Export JAVA_OPTS=" $JAVA_OPTS -Djava.sécurité.egd=file:///dev/urandom "

Je veux produire une réponse complémentaire de la solution de nacho-soriano...

Je recherche récemment pour résoudre un problème où une application écrite Java (un travail de Talend en fait) veut se connecter à une base de données Oracle (11g et plus) puis échouer de manière aléatoire. OS est à la fois RedHat Enterprise et CentOS. Le travail s'exécute très rapidement (pas plus d'une demi-minute) et se produit très souvent (environ une exécution toutes les 5 minutes).

Quelques fois, pendant la nuit comme temps de travail, pendant la base de données utilisation intensive du travail en tant qu'utilisation paresseuse du travail, en un mot au hasard, la connexion échoue avec ce message:

Exception in component tOracleConnection_1
java.sql.SQLRecoverableException: Io exception: Connection reset
        at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
        at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
        at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
        at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
        at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
        at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
        at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:465)
        at java.sql.DriverManager.getConnection(DriverManager.java:664)
        at java.sql.DriverManager.getConnection(DriverManager.java:208)
    and StackTrace follow ...

Explication du problème:

, Comme détaillé ici

Oracle connection a besoin de nombres aléatoires pour supposer un bon niveau de sécurité. Le générateur de nombres aléatoires Linux produit des bases de nombres activité clavier et souris (entre autres) et les place dans une pile. Vous allez m'accorder, sur un serveur, il n'est pas un gros montant d'une telle activité. Donc, il peut se produire que les logiciels utilisent plus de nombres aléatoires que le générateur peut produire.

Lorsque le pool est vide, les lectures de /dev/random se bloquent jusqu'à ce que du bruit environnemental supplémentaire soit recueilli. Et la connexion Oracle tombe dans le délai d'attente (60 secondes par défaut).

Solution 1-Spécifique pour une solution d'application

La solution consiste à ajouter deux paramètres donnés à la JVM lors du démarrage:

-Djava.security.egd=file:/dev/./urandom
-Dsecurerandom.source=file:/dev/./urandom

Remarque: avec/./ 'est important, ne le laissez pas tomber !

Donc la commande de lancement la ligne pourrait être:

java -Djava.security.egd=file:/dev/./urandom -Dsecurerandom.source=file:/dev/./urandom -cp <classpath directives> appMainClass <app options and parameters>

Un inconvénient de cette solution est que les nombres générés sont un peu moins sûrs car le caractère aléatoire est affecté. Si vous ne travaillez pas dans une industrie militaire ou secrète, cette solution peut être la vôtre.

Solution 2-Solution JVM Java générale

, Comme expliqué ici

Les deux directives données dans la solution 1 peuvent être placées dans le fichier de paramètres de sécurité Java.

Jetez un oeil à $JAVA_HOME/jre/lib/security/java.security

Changer le ligne

securerandom.source=file:/dev/random

À

securerandom.source=file:/dev/urandom

La modification prend effet immédiatement pour les nouvelles applications en cours d'exécution.

Quant à la solution #1, un inconvénient de cette solution est que les nombres générés sont un peu moins sûrs car le hasard est affecté. Cette fois, c'est un impact global de la JVM. En ce qui concerne la solution #1, si vous ne travaillez pas dans une industrie militaire ou secrète, cette solution peut être la vôtre.

Solution 3-Solution matérielle

Disclamer: Je ne suis pas lié à tout fournisseur de matériel ou de produit ...

Si votre besoin est d'atteindre un niveau aléatoire de haute qualité, vous pouvez remplacer votre logiciel de générateur de nombres aléatoires Linux par un morceau de matériel.

, Quelques informations sont disponibles ici.

Cordialement

Thomas

Solution
Changez la configuration de votre application, donc vous ce paramètre[-Djava.sécurité.egd = fichier: / dev/../dev/urandom] à côté de la commande java:

Java -Djava.sécurité.egd = fichier: / dev/../dev / urandom [votre commande]

Ref :- https://community.oracle.com/thread/943911

Votre exception dit tout "Réinitialisation de la connexion". La connexion entre votre processus java et le serveur db a été perdue, ce qui aurait pu se produire pour presque n'importe quelle raison(comme des problèmes de réseau). L'exception SQLRecoverableException signifie simplement qu'elle est récupérable, mais la cause première est la réinitialisation de la connexion.