I found a post from the Oracle official website forum. The problem discussed is similar to the problem I encountered, but the reason and solution to the problem raised are more interesting. According to the post, the root cause of the problem is related to the implementation principle of Java's secure random number generator.
java.security.SecureRandom is a standard API provided by sun. Among various methods offered by this class void nextBytes(byte[]) is one. This method is used for generating random bytes. Oracle 11g JDBC drivers use this API to generate random number during login. Users using Linux have been encountering SQLException(“Io exception: Connection reset”).
The problem is two fold
1. The JVM tries to list all the files in the /tmp (or alternate tmp directory set by -Djava.io.tmpdir) when SecureRandom.nextBytes(byte[]) is invoked. If the number of files is large the method takes a long time to respond and hence cause the server to timeout
2. The method void nextBytes(byte[]) uses /dev/random on Linux and on some machines which lack the random number generating hardware the operation slows down to the extent of bringing the whole login process to a halt. Ultimately the the user encounters SQLException(“Io exception:Connection reset”)
Users upgrading to 11g can encounter this issue if the underlying OS is Linux which is running on a faulty hardware.
CauseThe cause of this has not yet been determined exactly. It could either be a problem in your hardware or the fact that for some reason the software cannot read from /dev/random
SolutionChange the setup for your application, so you add the next parameter to the java command:
-Djava.security.egd=file:/dev/../dev/urandom
Field implementers are interested in the information in this post. In addition, after several retries in the test environment, the problem was successfully reproduced and the call stack when the problem occurred was successfully extracted. Analyzing the stack files extracted from the test environment, it is found that the calling process described in the above post is very similar, indicating that the method in the post is very promising to solve the problems I encountered. Therefore, according to the modification method in the post, multiple verifications were made in the test environment and the production environment, and I was pleasantly surprised to find that the problem was solved.
final solution
There are several ways to modify the JVM parameters of the application:
-Djava.security.egd=file:/dev/../dev/urandom
-Djava.security.egd=file:/dev/./urandom
-Djava.security.egd=file:/dev/urandom#It is said that there is a bug in this method, and no further verification has been done; I have not checked the code, so I don't know where the problem is.
Later, when I checked other information, I found that the original JRE's java.security file had already defined the variable java.security.egd.
#
# Select the source of seed data for SecureRandom. By default an
# attempt is made to use the entropy gathering device specified by
# the securerandom.source property. If an exception occurs when
# accessing the URL then the traditional system/thread activity
# algorithm is used.
#
# On Solaris and Linux systems, if file:/dev/urandom is specified and it
# exists, a special SecureRandom implementation is activated by default.
# This “NativePRNG” reads random bytes directly from /dev/urandom.
#
# On Windows systems, the URLs file:/dev/random and file:/dev/urandom
# enables use of the Microsoft CryptoAPI seed functionality.
#
securerandom.source=file:/dev/urandom
#
# The entropy gathering device is described as a URL and can also
# be specified with the system property “java.security.egd”. For example,
# -Djava.security.egd=file:/dev/urandom
# Specifying this system property will override the securerandom.source
# setting.
random number generator
If it is not to solve the problem, I will not deliberately check the underlying implementation related principles. This is a good opportunity. There are many introductions about /dev/random on the Internet, only the main points are listed:
1) /dev/random is a secure random number generation device provided by the Linux kernel;
2) /dev/random relies on system interrupt information to generate random numbers. When the number of devices is relatively small, the speed of generating random numbers is relatively slow. If the application's demand for random numbers is relatively large, the supply will be in short supply;
3) /dev/random will block the calling thread when reading;
4) /dev/urandom is an improved version of /dev/random, which solves the problem of slow random number generation and blocking calls, but at the same time slightly reduces security;
5) The man random command in the Linux environment can refer to the introduction of /dev/random and /dev/urandom, which is more detailed;
References
1)https://community.oracle.com/message/3701989
3)http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7003784
4)http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6202721