Analysis of HTTP Client POST Request Timeout Issues Caused by JDK Upgrade

A minor version upgrade of JDK, on CentOS systems led to timeout issues with third-party interface requests exposed to the outside environment, with no exceptions found in the logs, causing the interface to remain blocked.1. The scenario was reproduced, revealing that each time the request header was created, it remained blocked.

        SecureRandom secureRandom = new SecureRandom();        byte[] randomBytes = new byte[16]; // Generate a 16-byte random number, secure enough but won't significantly impact performance        secureRandom.nextBytes(randomBytes);        String sessionID = Base64.getEncoder().encodeToString(randomBytes); // Use Base64 encoding for easy transmission and storage

The blocking code is shown in the figure. By examining the blocking caused by nextBytes, and after analyzing the source code, the root cause of the failure was identified: the server’s entropy value was low, causing the service to hang while obtaining random numbers.2. Exception handling solutions for the inability to increase entropy:

Core Concept: What is Entropy?

In simple terms, the Linux kernel fills an “entropy pool” by collecting various unpredictable device noises (such as mouse movements, keyboard keystrokes, disk I/O time differences, etc.). This pool is the source of true random numbers generated by the system.<span>/dev/random</span> will block until there is enough entropy in the pool; while <span>/dev/urandom</span> will not block, but its randomness quality will decrease when entropy is insufficient.

On virtual machines, containers, or servers lacking physical input devices, the sources of entropy are minimal, making the entropy value prone to being too low.

Solutions

There are mainly two approaches to solve the low entropy issue: Increase entropy sources and use non-blocking alternatives.

Method 1: Install and configure <span><span>haveged</span></span> (recommended)

<span>haveged</span> is a daemon that generates entropy by utilizing the hardware timing jitter of the processor (an unpredictable noise) and injects it into the system’s entropy pool. It is a simple and effective solution, especially suitable for virtual machines and cloud environments.

Steps:

1 Check if <span><span>haveged is running</span></span>

 sudo systemctl status haveged

Confirm its status is <span>active (running)</span>. 2 Check the available entropy value; if it is greater than 1000, there generally won’t be any issues.

# Check current available entropy valuecat /proc/sys/kernel/random/entropy_avail

3 If not installed, install haveged

yum install haveged

4 Start haveged.

systemctl start haveged.service 

Method 2: Install and configure rng-tools<span>rng-tools</span> is another toolkit that can obtain entropy from hardware random number generators (if available) or use CPU instructions like <span>rdrand</span> to enhance the entropy pool.

Steps:

1. Install rng-tools

   sudo yum install rng-tools

2. Configuration (optional but recommended)

Edit <span>/etc/default/rng-tools</span> (Debian/Ubuntu) or <span>/etc/sysconfig/rngd</span> (RHEL/CentOS). Find the <span>HRNGDEVICE</span> configuration option. For modern Intel/AMD CPUs that support <span>rdrand</span> instruction, it can be set to <span>/dev/urandom</span>, allowing <span>rngd</span> to automatically use CPU instructions.

# For Debian/Ubuntu, edit /etc/default/rng-toolsHRNGDEVICE=/dev/urandom

3. Start and enable the service

sudo systemctl status rng-toolscat /proc/sys/kernel/random/entropy_avail

Method 3: Modify JRE secure random number generation to non-blocking mode (not recommended)

The culprit of this issue was the previous modification of the JDK configuration, which caused the JDK upgrade to behave abnormally.

Steps:

1. Navigate to

jre\lib\security

2. Modify the java.security file, changing securerandom.strongAlgorithms from the default blocking configuration to non-blocking

vim java.security 

3. Changesecurerandom.strongAlgorithms

 securerandom.strongAlgorithms = NativePRNGNonBlocking : SUN

Then restart the service

Summary and Recommendations

Method	Advantages	Disadvantages	Applicable Scenarios
Install <span>haveged</span>	Simple, lightweight, efficient, friendly to virtual machines	The quality of generated entropy is theoretically not as good as hardware sources	General recommendation, especially suitable for cloud servers and virtual machines
Install <span>rng-tools</span>	Can utilize hardware RNG, high entropy quality	Configuration is slightly complex, virtual machines may lack hardware RNG	Physical machines with hardware RNG or environments requiring the highest security
Use java.security	No need to install new software, quickly resolves blocking issues	May not be suitable for all applications, requires configuration changes	Solves slow startup issues for specific applications (like Java)

Best Practice Recommendations:

Best Practice Recommendations:

1. Preferred <span>haveged</span>: For most server environments, installing and enabling <span>haveged</span> is the most direct and effective solution.

2. Monitor entropy levels: You can periodically execute <span>cat /proc/sys/kernel/random/entropy_avail</span> to monitor the system’s entropy levels.

3. Use in combination: In production environments, you can install both <span>haveged</span> and <span>rng-tools</span> to ensure sufficient system entropy pool, while configuring known specific applications (like Tomcat) to use <span>java.security</span> as an additional safeguard.

By following the above methods, the issue of low entropy in your Linux environment should be perfectly resolved.