Er is een oplossing voor dit probleem in sommige van de OTN-forums (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Maar de oorzaak van het probleem wordt niet uitgelegd. Hieronder volgt mijn poging om de oorzaak van het probleem uit te leggen.
De Oracle JDBC-drivers communiceren op een veilige manier met de Oracle-server. De stuurprogramma's gebruiken de java.security.SecureRandom klasse om entropie te verzamelen voor het beveiligen van de communicatie. Deze klasse vertrouwt op de native platformondersteuning voor het verzamelen van de entropie.
Entropie is de willekeur die wordt verzameld/gegenereerd door een besturingssysteem of toepassing voor gebruik in cryptografie of ander gebruik waarvoor willekeurige gegevens nodig zijn. Deze willekeur wordt vaak verzameld uit hardwarebronnen, hetzij door hardwaregeluiden, audiogegevens, muisbewegingen of speciaal geleverde willekeurigheidsgeneratoren. De kernel verzamelt de entropie en slaat het op als een entropiepool en maakt de willekeurige karaktergegevens beschikbaar voor de processen of toepassingen van het besturingssysteem via de speciale bestanden /dev/random en /dev/urandom .
Lezen van /dev/random voert de entropiepool af met de gevraagde hoeveelheid bits/bytes, waardoor een hoge mate van willekeurigheid wordt geboden die vaak gewenst is bij cryptografische bewerkingen. Als de entropiepool volledig leeg is en er niet voldoende entropie beschikbaar is, kan de leesbewerking op /dev/random blokken totdat extra entropie is verzameld. Hierdoor kunnen applicaties lezen van /dev/random kan voor een willekeurige periode blokkeren.
In tegenstelling tot het bovenstaande, lezen uit de /dev/urandom blokkeert niet. Lezen van /dev/urandom , voert ook de entropiepool af, maar wanneer er onvoldoende entropie is, blokkeert het de bits van de gedeeltelijk gelezen willekeurige gegevens niet, maar hergebruikt ze deze opnieuw. Dit zou gevoelig zijn voor cryptanalytische aanvallen. Dit is een theoretische mogelijkheid en daarom wordt het afgeraden om te lezen uit /dev/urandom om willekeur te verzamelen in cryptografische bewerkingen.
De java.security.SecureRandom class leest standaard uit de /dev/random bestand en blokkeert daarom soms voor een willekeurige tijdsperiode. Nu, als de leesbewerking niet binnen de vereiste tijd terugkeert, geeft de Oracle-server een time-out voor de client (in dit geval de jdbc-stuurprogramma's) en verbreekt de communicatie door de socket vanaf het einde te sluiten. De client die de communicatie probeert te hervatten nadat hij is teruggekeerd van de blokkerende oproep, komt de IO-uitzondering tegen. Dit probleem kan willekeurig optreden op elk platform, vooral waar de entropie wordt verzameld uit hardwareruis.
Zoals gesuggereerd in het OTN-forum, is de oplossing voor dit probleem het negeren van het standaardgedrag van java.security.SecureRandom class om de niet-blokkerende read van /dev/urandom . te gebruiken in plaats van het blokkeren van lezen van /dev/random . Dit kan gedaan worden door de volgende systeemeigenschap -Djava.security.egd=file:///dev/urandom toe te voegen naar de JVM. Hoewel dit een goede oplossing is voor toepassingen zoals de JDBC-stuurprogramma's, wordt het afgeraden voor toepassingen die cryptografische kernbewerkingen uitvoeren, zoals het genereren van cryptografische sleutels.
Andere oplossingen kunnen zijn om verschillende random seeder-implementaties te gebruiken die beschikbaar zijn voor het platform en die niet afhankelijk zijn van hardwareruis voor het verzamelen van entropie. Hiermee moet u mogelijk nog steeds het standaardgedrag van java.security.SecureRandom overschrijven .
Het verhogen van de socket-time-out aan de Oracle-serverzijde kan ook een oplossing zijn, maar de bijwerkingen moeten worden beoordeeld vanuit het oogpunt van de server voordat u dit probeert.