Se proporciona una solución a este problema en algunos de los foros de OTN (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Pero, la causa raíz del problema no se explica. A continuación, mi intento de explicar la causa raíz del problema.
Los controladores Oracle JDBC se comunican con el servidor Oracle de forma segura. Los controladores usan java.security.SecureRandom clase para reunir entropía para asegurar la comunicación. Esta clase se basa en el soporte de la plataforma nativa para recopilar la entropía.
Entropía es la aleatoriedad recopilada/generada por un sistema operativo o una aplicación para su uso en criptografía u otros usos que requieren datos aleatorios. Esta aleatoriedad a menudo se recopila de fuentes de hardware, ya sea de ruidos de hardware, datos de audio, movimientos del mouse o generadores de aleatoriedad especialmente proporcionados. El núcleo recopila la entropía y la almacena en un grupo de entropía y pone los datos de caracteres aleatorios a disposición de los procesos o aplicaciones del sistema operativo a través de los archivos especiales /dev/random y /dev/urandom .
Lectura de /dev/random drena el grupo de entropía con la cantidad solicitada de bits/bytes, proporcionando un alto grado de aleatoriedad que a menudo se desea en las operaciones criptográficas. En caso de que el grupo de entropía esté completamente agotado y no haya suficiente entropía disponible, la operación de lectura en /dev/random bloques hasta que se reúne entropía adicional. Debido a esto, las aplicaciones que leen desde /dev/random puede bloquearse durante un período de tiempo aleatorio.
En contraste con lo anterior, leer del /dev/urandom no bloquea Lectura de /dev/urandom , también drena el grupo de entropía, pero cuando no tiene suficiente entropía, no bloquea sino que reutiliza los bits de los datos aleatorios parcialmente leídos. Se dice que esto es susceptible a ataques criptoanalíticos. Esta es una posibilidad teórica y, por lo tanto, se desaconseja leer desde /dev/urandom para recopilar aleatoriedad en operaciones criptográficas.
java.security.SecureRandom class, por defecto, lee desde el /dev/random archivo y, por lo tanto, a veces se bloquea durante un período de tiempo aleatorio. Ahora, si la operación de lectura no regresa durante un período de tiempo requerido, el servidor de Oracle agota el tiempo del cliente (los controladores jdbc, en este caso) y interrumpe la comunicación cerrando el socket desde su extremo. El cliente cuando intenta reanudar la comunicación después de regresar de la llamada de bloqueo encuentra la excepción IO. Este problema puede ocurrir aleatoriamente en cualquier plataforma, especialmente, donde la entropía se obtiene de los ruidos del hardware.
Como se sugirió en el foro de OTN, la solución a este problema es anular el comportamiento predeterminado de java.security.SecureRandom clase para usar la lectura sin bloqueo de /dev/urandom en lugar de la lectura de bloqueo de /dev/random . Esto se puede hacer agregando la siguiente propiedad del sistema -Djava.security.egd=file:///dev/urandom a la JVM. Aunque esta es una buena solución para aplicaciones como los controladores JDBC, no se recomienda para aplicaciones que realizan operaciones criptográficas básicas como la generación de claves criptográficas.
Otras soluciones podrían ser usar diferentes implementaciones de sembrador aleatorio disponibles para la plataforma que no dependan de los ruidos del hardware para recopilar entropía. Con esto, es posible que aún necesite anular el comportamiento predeterminado de java.security.SecureRandom .
Aumentar el tiempo de espera del socket en el lado del servidor de Oracle también puede ser una solución, pero los efectos secundarios deben evaluarse desde el punto de vista del servidor antes de intentarlo.
