Det finns en lösning på detta problem i några av OTN-forumen (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Men grundorsaken till problemet förklaras inte. Nedan följer mitt försök att förklara grundorsaken till problemet.
Oracle JDBC-drivrutinerna kommunicerar med Oracle-servern på ett säkert sätt. Drivrutinerna använder java.security.SecureRandom klass för att samla in entropi för att säkra kommunikationen. Den här klassen förlitar sig på det inbyggda plattformsstödet för att samla in entropin.
Entropi är den slumpmässighet som samlas in/genereras av ett operativsystem eller en applikation för användning i kryptografi eller annan användning som kräver slumpmässig data. Denna slumpmässighet samlas ofta in från hårdvarukällor, antingen från hårdvaruljud, ljuddata, musrörelser eller speciellt tillhandahållna slumpgeneratorer. Kärnan samlar in entropin och lagrar att den är en entropipool och gör slumpmässiga teckendata tillgänglig för operativsystemets processer eller applikationer genom specialfilerna /dev/random och /dev/urandom .
Läser från /dev/random dränerar entropipoolen med efterfrågad mängd bitar/byte, vilket ger en hög grad av slumpmässighet som ofta önskas i kryptografiska operationer. Om entropipoolen är helt dränerad och tillräcklig entropi inte är tillgänglig, läsoperationen på /dev/random block tills ytterligare entropi har samlats in. På grund av detta läser applikationer från /dev/random kan blockera under en slumpmässig tidsperiod.
I motsats till ovanstående, läsning från /dev/urandom blockerar inte. Läser från /dev/urandom tömmer också entropipoolen men när den saknar tillräcklig entropi blockerar den inte utan återanvänder bitarna från de delvis lästa slumpmässiga data. Detta sägs vara känsligt för kryptoanalytiska attacker. Detta är en teoretisk möjlighet och därför avråds det från att läsa från /dev/urandom att samla in slumpmässighet i kryptografiska operationer.
java.security.SecureRandom klass läser som standard från /dev/random fil och blockerar därför ibland under en slumpmässig tidsperiod. Om nu läsoperationen inte återkommer under en erforderlig tid, tar Oracle-servern timeout för klienten (jdbc-drivrutinerna, i det här fallet) och avbryter kommunikationen genom att stänga sockeln från dess ände. När klienten försöker återuppta kommunikationen efter att ha återvänt från det blockerande samtalet stöter på IO-undantaget. Det här problemet kan uppstå slumpmässigt på vilken plattform som helst, särskilt där entropin samlas in från hårdvaruljud.
Som föreslagits i OTN-forumet är lösningen på detta problem att åsidosätta standardbeteendet för java.security.SecureRandom klass för att använda den icke-blockerande läsningen från /dev/urandom istället för att blockera läs från /dev/random . Detta kan göras genom att lägga till följande systemegenskap -Djava.security.egd=file:///dev/urandom till JVM. Även om detta är en bra lösning för applikationer som JDBC-drivrutinerna, avråds den från applikationer som utför centrala kryptografiska operationer som krytografisk nyckelgenerering.
Andra lösningar kan vara att använda olika slumpmässiga seeder-implementationer tillgängliga för plattformen som inte förlitar sig på hårdvaruljud för att samla in entropi. Med detta kan du fortfarande behöva åsidosätta standardbeteendet för java.security.SecureRandom .
Att öka sockets timeout på Oracle-serversidan kan också vara en lösning, men biverkningarna bör bedömas från serverns synvinkel innan du försöker göra detta.