Solving the problem that java program obtains oracle database connection timeout in Linux environment

Running a java program (jdk 1.7) under Linux, the program will obtain the Oracle database connection. In order to improve the processing speed, multiple processes are used to start the processing in parallel. At this time, an exception that the database connection fails to obtain a timeout occasionally occurs. And the windows environment No problem below.

 

java.sql.SQLException: IO Error: End of TNS data channel
 at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:458)
 at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:546)
 at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:236)
 at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)


or

java.sql.SQLException: IO Error: Connection reset
 at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:467)
 at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:546)
 at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:236)
 at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)

 

Solution:

       When java starts, add the startup parameter "-Djava.security.egd=file:/dev/./urandom"

Note: "-Djava.security.egd=file:/dev/urandom" is equivalent to "-Djava.security.egd=file:/dev/random"

 

Cause Analysis

       Oracle's JDBC driver program uses Java's SecureRandom to obtain a random byte data stream when it obtains a db connection, which is used to generate random numbers. The -Djava.security.egd configuration is a pseudo-device for random data collection, which is available under linux. Two:

       1./dev/random, use system interrupts to generate random data, so when the system is not very busy, the number of interrupts is small, then the calling process will enter the waiting state, until there are enough interrupts, it will be Returns a random number, and the getConnection timeout may have occurred at this time

       2. /dev/urandom, does not use system interrupts to generate random numbers, so it will not cause the calling process to wait

Therefore, we must use urandom in our situation. Due to the bug of java, even if file:/dev/urandom is specified, SecureRandom still uses random. In order to bypass this bug, we found "-Djava.security. egd=file:/dev/./urandom" is a configuration method to achieve our purpose of using urandom.

 

 In order to verify the speed before and after the configuration, the following applet can be used for comparison and confirmation

JRand.java

 

import java.security.SecureRandom;
class JRand {
    public static void main(String args[]) throws Exception {
        System.out.println("Ok: " +
            SecureRandom.getInstance("SHA1PRNG").nextLong());
    }
}



time java -Djava.security.egd=file:/dev/urandom  JRand

time java -Djava.security.egd=file:/dev/./urandom  JRand