Il existe une solution à ce problème dans certains forums OTN (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Mais, la cause première du problème n'est pas expliquée. Voici ma tentative d'expliquer la cause première du problème.
Les pilotes Oracle JDBC communiquent avec le serveur Oracle de manière sécurisée. Les pilotes utilisent le java.security.SecureRandom classe pour recueillir l'entropie pour sécuriser la communication. Cette classe s'appuie sur la prise en charge de la plate-forme native pour collecter l'entropie.
Entropie est le caractère aléatoire collecté/généré par un système d'exploitation ou une application pour une utilisation en cryptographie ou d'autres utilisations nécessitant des données aléatoires. Ce caractère aléatoire est souvent collecté à partir de sources matérielles, soit à partir des bruits matériels, des données audio, des mouvements de souris ou de générateurs de caractère aléatoire spécialement fournis. Le noyau rassemble l'entropie et la stocke dans un pool d'entropie et met les données de caractères aléatoires à la disposition des processus ou des applications du système d'exploitation via les fichiers spéciaux /dev/random et /dev/urandom .
Lecture depuis /dev/random draine le pool d'entropie avec la quantité demandée de bits/octets, fournissant un degré élevé de caractère aléatoire souvent souhaité dans les opérations cryptographiques. Dans le cas où le pool d'entropie est complètement vidé et qu'une entropie suffisante n'est pas disponible, l'opération de lecture sur /dev/random bloque jusqu'à ce qu'une entropie supplémentaire soit collectée. Pour cette raison, les applications lisant depuis /dev/random peut bloquer pendant une période de temps aléatoire.
Contrairement à ce qui précède, la lecture à partir de /dev/urandom ne bloque pas. Lecture depuis /dev/urandom , également, draine le pool d'entropie mais lorsqu'il manque d'entropie suffisante, il ne bloque pas mais réutilise les bits des données aléatoires partiellement lues. On dit que cela est sensible aux attaques cryptanalytiques. C'est une possibilité théorique et il est donc déconseillé de lire depuis /dev/urandom pour rassembler le hasard dans les opérations cryptographiques.
Le java.security.SecureRandom classe, par défaut, lit à partir de /dev/random fichier et donc parfois bloque pendant une période de temps aléatoire. Maintenant, si l'opération de lecture ne revient pas pendant un laps de temps requis, le serveur Oracle expire le client (les pilotes jdbc, dans ce cas) et abandonne la communication en fermant le socket à partir de sa fin. Le client, lorsqu'il tente de reprendre la communication après être revenu de l'appel bloquant, rencontre l'exception IO. Ce problème peut se produire de manière aléatoire sur n'importe quelle plate-forme, en particulier lorsque l'entropie est collectée à partir de bruits matériels.
Comme suggéré dans le forum OTN, la solution à ce problème est de remplacer le comportement par défaut de java.security.SecureRandom classe pour utiliser la lecture non bloquante de /dev/urandom au lieu du blocage lu depuis /dev/random . Cela peut être fait en ajoutant la propriété système suivante -Djava.security.egd=file:///dev/urandom à la JVM. Bien qu'il s'agisse d'une bonne solution pour les applications telles que les pilotes JDBC, elle est déconseillée pour les applications qui effectuent des opérations cryptographiques de base telles que la génération de clés cryptographiques.
D'autres solutions pourraient consister à utiliser différentes implémentations de semences aléatoires disponibles pour la plate-forme qui ne reposent pas sur les bruits matériels pour collecter l'entropie. Avec cela, vous devrez peut-être toujours remplacer le comportement par défaut de java.security.SecureRandom .
L'augmentation du délai d'expiration du socket côté serveur Oracle peut également être une solution, mais les effets secondaires doivent être évalués du point de vue du serveur avant d'essayer.
