Existuje řešení tohoto problému na některých fórech OTN (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Ale hlavní příčina problému není vysvětlena. Následuje můj pokus vysvětlit hlavní příčinu problému.
Ovladače Oracle JDBC komunikují se serverem Oracle bezpečným způsobem. Ovladače používají java.security.SecureRandom třídy shromáždit entropii pro zabezpečení komunikace. Tato třída spoléhá na podporu nativní platformy pro shromažďování entropie.
Entropie je náhodnost shromážděná/vygenerovaná operačním systémem nebo aplikací pro použití v kryptografii nebo jiném použití, které vyžaduje náhodná data. Tato náhodnost je často shromažďována z hardwarových zdrojů, buď z hardwarových ruchů, zvukových dat, pohybů myši nebo speciálně poskytnutých generátorů náhodnosti. Jádro shromažďuje entropii a ukládá ji jako fond entropie a zpřístupňuje data náhodných znaků procesům nebo aplikacím operačního systému prostřednictvím speciálních souborů /dev/random a /dev/urandom .
Čtení z /dev/random vyčerpá zásobu entropie požadovaným množstvím bitů/bajtů, čímž poskytuje vysoký stupeň náhodnosti, který je často požadovaný v kryptografických operacích. V případě, že je fond entropie zcela vyčerpaný a není k dispozici dostatečná entropie, operace čtení na /dev/random bloků, dokud se neshromáždí další entropie. Kvůli tomu aplikace čtou z /dev/random může blokovat na nějakou náhodnou dobu.
Na rozdíl od výše uvedeného, čtení z /dev/urandom neblokuje. Čtení z /dev/urandom , také vyčerpává zásobu entropie, ale když nedosahuje dostatečné entropie, neblokuje, ale znovu používá bity z částečně přečtených náhodných dat. To je prý náchylné ke kryptanalytickým útokům. Toto je teoretická možnost, a proto se nedoporučuje číst z /dev/urandom shromažďovat náhodnost v kryptografických operacích.
java.security.SecureRandom třída ve výchozím nastavení čte z /dev/random soubor, a proto někdy blokuje na náhodnou dobu. Nyní, pokud se operace čtení nevrátí po požadovanou dobu, server Oracle vyprší časový limit klienta (v tomto případě ovladače jdbc) a ukončí komunikaci uzavřením soketu od jeho konce. Klient při pokusu o obnovení komunikace po návratu z blokovacího volání narazí na výjimku IO. K tomuto problému může dojít náhodně na jakékoli platformě, zejména tam, kde je entropie získávána z hardwarových šumů.
Jak bylo navrženo na fóru OTN, řešením tohoto problému je přepsat výchozí chování java.security.SecureRandom třídy použít neblokující čtení z /dev/urandom místo blokování čtení z /dev/random . To lze provést přidáním následující systémové vlastnosti -Djava.security.egd=file:///dev/urandom do JVM. Ačkoli je to dobré řešení pro aplikace, jako jsou ovladače JDBC, nedoporučuje se to u aplikací, které provádějí základní kryptografické operace, jako je generování kryptografických klíčů.
Dalším řešením by mohlo být použití různých implementací náhodného osiva dostupných pro platformu, které se při shromažďování entropie nespoléhají na hardwarové zvuky. Díky tomu můžete stále vyžadovat přepsání výchozího chování java.security.SecureRandom .
Řešením může být také zvýšení časového limitu soketu na straně serveru Oracle, ale než se o to pokusíte, měly by být vedlejší účinky posouzeny z hlediska serveru.