When an old project will soon be transplanted to ARM version of CentOS7, I met SpringBoot start well, but stuck to access the page problem. Because it is aarch64 architecture, using openjdk, we have been using Oracle's ServerJRE, no problems were encountered in the x86_64 environment before the project. The normal start, but after starting is completed, the access part of the normal page, some pages will be stuck, stuck time is not fixed, sometimes long and sometimes short, there is no law at all. And when the jammed page normal, then refresh does not get stuck again.
The first idea is certainly to check the log, when you first visit the page Caton, Spring framework there is a such a WARN:
2019-12-09 17:40:32.995 WARN 15161 --- [https-jsse-nio-443-exec-8] o.a.c.util.SessionIdGeneratorBase : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [178,241] milliseconds.
Session create SecureRandom instance took nearly three minutes, which is why the jammed page also explains why only some of the pages stuck, because not all pages using the Session, as well as resolve why the jammed page to access then refresh normal, because SecureRandom instance is created only once. 2019-12-09 17: 40: 32.995 WARN 15161 --- [https-jsse-nio-443-exec-8] oacutil.SessionIdGeneratorBase: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [178,241] milliseconds.
Turned back to look at the reasons, the project was used as an embedded Tomcat Embed WEB server, and Tomcat will use org.apache.catalina.util.SessionIdGeneratorBase when generating random session ID to generate the security class SecureRandom instance. To algorithm cryptographically stronger, the need to use a pseudo-random number generator, Tomcat SHA1PRNG algorithm is used, in order to obtain a random seed, typically generated from / dev / random or / dev / urandom in Linux, both the principle It is the use of ambient noise of the system to generate a number of random bits, except that the system is not enough ambient noise, random clog, and urandom avoid blocking the expense of safety.
Caton phenomenon from the point of view, it must be with the / dev / random due to look at $ JAVA_HOME / jre / lib / security / java.security file, find the following:
#
# Sun Provider SecureRandom seed source.
#
# Select the primary source of seed data for the "SHA1PRNG" and
# "NativePRNG" SecureRandom implementations in the "Sun" provider.
# (Other SecureRandom implementations might also use this property.)
#
# On Unix-like systems (for example, Solaris/Linux/MacOS), the
# "NativePRNG" and "SHA1PRNG" implementations obtains seed data from
# special device files such as file:/dev/random.
#
# On Windows systems, specifying the URLs "file:/dev/random" or
# "file:/dev/urandom" will enable the native Microsoft CryptoAPI seeding
# mechanism for SHA1PRNG.
#
# By default, an attempt is made to use the entropy gathering device
# specified by the "securerandom.source" Security property. If an
# exception occurs while accessing the specified URL:
#
# SHA1PRNG:
# the traditional system/thread activity algorithm will be used.
#
# NativePRNG:
# a default value of /dev/random will be used. If neither
# are available, the implementation will be disabled.
# "file" is the only currently supported protocol type.
#
# The entropy gathering device can also be specified with the System
# property "java.security.egd". For example:
#
# % java -Djava.security.egd=file:/dev/random MainClass
#
# Specifying this System property will override the
# "securerandom.source" Security property.
#
# In addition, if "file:/dev/random" or "file:/dev/urandom" is
# specified, the "NativePRNG" implementation will be more preferred than
# SHA1PRNG in the Sun provider.
#
securerandom.source=file:/dev/random
Really use the / dev / random, according to the comment section above solution is not complicated, startup parameters may be added or modified java.security:
Solution 1:
start-up parameters -Djava.security.egd = file: / dev / urandom , such as:
java -Djava.security.egd=file:/dev/urandom -jar xxxxx.jar
Solution 2:
Modify the $ JAVA_HOME / jre / lib / security / java.security, and find securerandom.source Review:
securerandom.source=file:/dev/urandom
And then restart the site, Caton phenomenon disappears.