You can achieve it by passing the following JVM argument to your application during startup: =file:/dev/. However, it has the downside of reduced security due to less randomness. ‘/dev/urandom’ is another special file that is capable of generating random numbers. You can configure it to use ‘/dev/urandom’ instead of ‘/dev/random’. Java uses this file to generate random numbers. Unix-like operating systems come up with special file ‘/dev/random’ that serve as pseudorandom number generators. On Redhat platforms (RHEL, Fedora, CentOS): sudo yum install rng-toolsģ. On Debian based platforms (Debian, Ubuntu): sudo apt-get install rng-tools Here is the ‘Haveged’ project GIT repository page. The ‘ haveged project‘ is meant to provide an easy-to-use, unpredictable random number generator based upon an adaptation of the HAVEGE algorithm.
If your application is running in Linux, then you consider installing the ‘haveged’ library. So, if you can upgrade your JDK, please do so. However, it’s been fixed since JDK8u112 or JDK9b105. This problem is stemming because of a known bug in Java. If this problem surfaces in your application, the following are the potential solutions to address them: 1. Thus it was making the application unresponsive. You can notice that the thread got into a BLOCKED state when invoking ‘#randomUUID()’ due to a lack of ‘entropy’ and unable to progress forward. (ExecuteThread.java:221)įig: Stack trace of a thread stuck while making ‘#randomUUID()’ API call Java Unique Number Generator - UUID Used to represent a primary key in a database table can be used as Session ID in web applications, Transaction Id in. securedExecute(WebAppServletContext.java:2273) AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) $ServletInvocationAction.wrapRun(WebAppServletContext.java:3730) (SecureRandom.java:433)Ĭom.topComponentMethodBbuggycompanyin(RootTracer.java:439) Below is the stack trace of one of that 50 threads: " ExecuteThread: '1' for queue: ' (self-tuning)'" waiting for lock BLOCKED In these 102 threads 50 threads are in the BLOCKED state due to ‘#randomUUID()’ API call. In the thread dump report, you can notice that there are 102 threads in total. (Note: in the thread dump report, we have changed the package name to ‘buggycompany’ to hide the identity of the application). It would give the better context of the problem.
If you haven’t clicked on the hyperlink in the previous sentence, we request you do so. Here is a real-world thread dump report of an application that was suffering from this problem. Real world application – 50 threads BLOCKED in #randomUUID() API Return Long.toHexString(MSB | ng.nextLong()) + Long.toHexString(MSB | ng.If your application uses ‘#randomUUID()’ API in a critical code path and there is a lack of entropy in the operating system, then multiple threads can enter into this BLOCKED state bringing your entire application to a grinding halt. NumberGenerator = ng = new SecureRandom() Private static volatile SecureRandom numberGenerator = null Maxim: Copied from UUID implementation :) Note that I'm not generating a UUID, instead just a random 32 bytes hex string in the most efficient way I could think of. Ended up writing something of my own based on UUID.java implementation.
0 kommentar(er)
