I want to give an additional answer about the nacho-soriano solution ...
I recently tried to solve a problem when a Java-written application (actually this is a Talend ELT job) wants to connect to an Oracle database (11g or more), and then a crash happens by accident. Operating system RedHat Enterprise and CentOS. The task runs very quickly in time (no more than half a minute) and runs very often (approximately one run every 5 minutes).
Sometimes, at night, as working hours, during intensive use of the database in the form of lazy use, in a word, randomly, the connection with this message fails:
Exception in component tOracleConnection_1 java.sql.SQLRecoverableException: Io exception: Connection reset at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458) at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411) at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490) at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202) at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33) at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:465) at java.sql.DriverManager.getConnection(DriverManager.java:664) at java.sql.DriverManager.getConnection(DriverManager.java:208) and StackTrace follow ...
Explanation of the problem:
As detailed here
An Oracle connection requires random numbers to provide a good level of security. Linux random number generator generates some numbers based on keyboard and mouse activity (among others) and pushes them on the stack. You will give me, on the server, there is not a lot of such activity. So it may happen that programs use more random numbers than a generator can produce.
When the pool is empty, reading from / dev / random will be blocked until additional environmental noise is collected. And the Oracle connection timed out (60 seconds by default).
Solution 1 - Specially for one application
The solution is to add two parameters specified by the JVM at startup:
-Djava.security.egd=file:/dev/./urandom -Dsecurerandom.source=file:/dev/./urandom
Note: "/./" is important, do not drop it!
Thus, the launch command line can be:
java -Djava.security.egd=file:/dev/./urandom -Dsecurerandom.source=file:/dev/./urandom -cp <classpath directives> appMainClass <app options and parameters>
One of the drawbacks of this solution is that the generated numbers are slightly less secure due to the influence of randomness. If you are not working in the military or secret industry, this decision may be yours.
Solution 2 - Generic Java JVM Solution
As explained here
Both directives in solution 1 can be placed in the Java security settings file.
Take a look at $JAVA_HOME/jre/lib/security/java.security
Change line
securerandom.source=file:/dev/random
in
securerandom.source=file:/dev/urandom
The change takes effect immediately for newly launched applications.
As for solution No. 1, one of the drawbacks of this solution is that the generated numbers are slightly less secure due to the influence of randomness. This time it's the global influence of the JVM. As for Decision No. 1, if you are not working in the military or secret industry, this decision may be yours.
Ideally, we should use "file: /dev/./urandom" after Java 5, since the previous path will again point to / dev / random.
Reported error: https://bugs.openjdk.java.net/browse/JDK-6202721
Solution 3 - Hardware Solution
Disclaimer: I am not affiliated with any of the suppliers of equipment or product ...
If you need to achieve a high level of randomness, you can replace the software of your Linux random number generator with hardware.
Some information is available here .
respectfully
Thomas