Има решение на този проблем в някои от форумите на OTN (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989). Но основната причина за проблема не е обяснена. Следва опитът ми да обясня основната причина за проблема.
Oracle JDBC драйверите комуникират със сървъра на Oracle по защитен начин. Драйверите използват java.security.SecureRandom клас за събиране на ентропия за осигуряване на комуникацията. Този клас разчита на поддръжката на собствената платформа за събиране на ентропията.
Ентропия е случайността, събрана/генерирана от операционна система или приложение за използване в криптография или други употреби, които изискват произволни данни. Тази случайност често се събира от хардуерни източници, или от хардуерни шумове, аудио данни, движения на мишката или специално предоставени генератори на случайност. Ядрото събира ентропията и я съхранява като ентропийен пул и прави произволните знаци достъпни за процесите или приложенията на операционната система чрез специалните файлове /dev/random и /dev/urandom .
Четене от /dev/random източва ентропийния пул със заявено количество битове/байтове, осигурявайки висока степен на произволност, често желана при криптографски операции. В случай, че ентропийният пул е напълно изтощен и няма достатъчно ентропия, операцията за четене на /dev/random блокове, докато се събере допълнителна ентропия. Поради това приложенията четат от /dev/random може да блокира за произволен период от време.
За разлика от горното, четене от /dev/urandom не блокира. Четене от /dev/urandom , също източва ентропийния пул, но когато липсва достатъчна ентропия, той не блокира, а използва повторно битовете от частично прочетените произволни данни. Твърди се, че това е податливо на криптоаналитични атаки. Това е теоретична възможност и следователно не се препоръчва да се чете от /dev/urandom за събиране на случайност в криптографски операции.
java.security.SecureRandom клас, по подразбиране, чете от /dev/random файл и следователно понякога блокира за произволен период от време. Сега, ако операцията за четене не се върне за необходимия период от време, сървърът на Oracle изчерпва клиента (в този случай jdbc драйверите) и прекратява комуникацията, като затваря сокета от неговия край. Клиентът, когато се опитва да възобнови комуникацията след връщане от блокиращото повикване, среща изключението за IO. Този проблем може да възникне произволно на всяка платформа, особено където ентропията се събира от хардуерни шумове.
Както беше предложено във форума на OTN, решението на този проблем е да се отмени поведението по подразбиране на java.security.SecureRandom клас, за да използвате неблокиращото четене от /dev/urandom вместо блокиращото четене от /dev/random . Това може да стане чрез добавяне на следното системно свойство -Djava.security.egd=file:///dev/urandom към JVM. Въпреки че това е добро решение за приложения като JDBC драйверите, не се препоръчва за приложения, които изпълняват основни криптографски операции, като генериране на криптографски ключ.
Други решения могат да бъдат използването на различни произволни реализации за сеялка, налични за платформата, които не разчитат на хардуерни шумове за събиране на ентропия. С това все пак може да се наложи да отмените поведението по подразбиране на java.security.SecureRandom .
Увеличаването на времето за изчакване на сокета от страната на сървъра на Oracle също може да бъде решение, но страничните ефекти трябва да бъдат оценени от гледна точка на сървъра, преди да се опитате да направите това.
