Der er en løsning på dette problem i nogle af OTN-foraene (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Men årsagen til problemet er ikke forklaret. Følgende er mit forsøg på at forklare årsagen til problemet.
Oracle JDBC-driverne kommunikerer med Oracle-serveren på en sikker måde. Driverne bruger java.security.SecureRandom klasse for at indsamle entropi for at sikre kommunikationen. Denne klasse er afhængig af den oprindelige platformsunderstøttelse til at indsamle entropien.
Entropi er den tilfældighed, der indsamles/genereres af et operativsystem eller en applikation til brug i kryptografi eller anden anvendelse, der kræver tilfældige data. Denne tilfældighed indsamles ofte fra hardwarekilder, enten fra hardwarestøj, lyddata, musebevægelser eller specielt leverede tilfældighedsgeneratorer. Kernen samler entropien og gemmer, at den er en entropipulje og gør de tilfældige tegndata tilgængelige for operativsystemets processer eller programmer gennem specialfilerne /dev/random og /dev/urandom .
Læser fra /dev/random dræner entropipuljen med den ønskede mængde bits/bytes, hvilket giver en høj grad af tilfældighed, der ofte ønskes i kryptografiske operationer. Hvis entropipuljen er fuldstændig drænet og tilstrækkelig entropi ikke er tilgængelig, kan læseoperationen på /dev/random blokke indtil yderligere entropi er samlet. På grund af dette læser applikationer fra /dev/random kan blokere i et tilfældigt tidsrum.
I modsætning til ovenstående læser du fra /dev/urandom blokerer ikke. Læser fra /dev/urandom også dræner entropipuljen, men når den mangler tilstrækkelig entropi, blokerer den ikke, men genbruger bitsene fra de delvist læste tilfældige data. Dette siges at være modtageligt for kryptoanalytiske angreb. Dette er en teoretisk mulighed, og derfor frarådes det at læse fra /dev/urandom at indsamle tilfældighed i kryptografiske operationer.
java.security.SecureRandom klasse læser som standard fra /dev/random fil og blokerer derfor nogle gange i tilfældige tidsrum. Nu, hvis læseoperationen ikke vender tilbage i et påkrævet tidsrum, vil Oracle-serveren timeout for klienten (i dette tilfælde jdbc-driverne) og afbryde kommunikationen ved at lukke soklen fra dens ende. Når klienten forsøger at genoptage kommunikationen efter at være vendt tilbage fra det blokerende opkald, støder han på IO-undtagelsen. Dette problem kan opstå tilfældigt på enhver platform, især hvor entropien er indsamlet fra hardwarestøj.
Som foreslået i OTN-forummet er løsningen på dette problem at tilsidesætte standardadfærden for java.security.SecureRandom klasse for at bruge den ikke-blokerende læsning fra /dev/urandom i stedet for blokeringen læses fra /dev/random . Dette kan gøres ved at tilføje følgende systemegenskab -Djava.security.egd=file:///dev/urandom til JVM. Selvom dette er en god løsning til applikationer som JDBC-drivere, frarådes det applikationer, der udfører centrale kryptografiske operationer såsom krytografisk nøglegenerering.
Andre løsninger kunne være at bruge forskellige tilfældige seeder-implementeringer, der er tilgængelige for platformen, og som ikke er afhængige af hardwarestøj til at indsamle entropi. Med dette kan du stadig kræve at tilsidesætte standardadfærden for java.security.SecureRandom .
Forøgelse af socket-timeout på Oracle-serversiden kan også være en løsning, men bivirkningerne bør vurderes fra serverens synspunkt, før du forsøger dette.