JSF application start up hangs on EAP 7.4 Update 15-16

Environment

• Red Hat JBoss Enterprise Application Platform (EAP)
  • 7.4.15 (CP15)
  • 7.4.16 (CP16)

Issue

• After updating to EAP 7.4 Update 15, our JSF application start up takes excessively long. Reverting to EAP 7.4 Update 14 corrects this long start up. Thread dumps show the app start up is stalled here in SecureRandom.nextBytes:

"ServerService Thread Pool -- 74" #117 prio=5 os_prio=0 tid=0x0000561c6a331800 nid=0xd1546 runnable [0x00007f3062465000]
   java.lang.Thread.State: RUNNABLE
	at java.io.FileInputStream.readBytes(Native Method)
	at java.io.FileInputStream.read(FileInputStream.java:255)
	at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424)
	at sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:526)
	at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:545)
	- locked <0x00000000aef67fd0> (a java.lang.Object)
	at sun.security.provider.NativePRNG$RandomIO.access$400(NativePRNG.java:331)
	at sun.security.provider.NativePRNG$Blocking.engineNextBytes(NativePRNG.java:268)
	at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
	at com.sun.faces.lifecycle.TokenGenerator.generateSeed(TokenGenerator.java:61)
	at com.sun.faces.lifecycle.TokenGenerator.<init>(TokenGenerator.java:33)
	at com.sun.faces.lifecycle.ClientWindowFactoryImpl.<init>(ClientWindowFactoryImpl.java:35)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at javax.faces.FactoryFinderInstance.getImplGivenPreviousImpl(FactoryFinderInstance.java:466)
	at javax.faces.FactoryFinderInstance.getImplementationInstance(FactoryFinderInstance.java:356)
	at javax.faces.FactoryFinderInstance.getFactory(FactoryFinderInstance.java:202)
	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:279)
	at com.sun.faces.config.processor.FactoryConfigProcessor.lambda$verifyFactoriesExist$0(FactoryConfigProcessor.java:303)
	at com.sun.faces.config.processor.FactoryConfigProcessor$$Lambda$1546/967980244.accept(Unknown Source)
	at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
	at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:297)
	at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:211)
	at com.sun.faces.config.ConfigManager.lambda$initialize$0(ConfigManager.java:295)
	at com.sun.faces.config.ConfigManager$$Lambda$1545/1492163987.accept(Unknown Source)
	at java.util.Iterator.forEachRemaining(Iterator.java:116)
	at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:293)
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:210)
	at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)

Resolution

• Apply patch This content is not included.EAP 7.4 Update 17 to fix this bug This content is not included.JBEAP-26824.

• Workaround :-

  • To avoid this delay in generating the token seed, you can change the java securerandom.strongAlgorithms security property to use a non blocking source. To adjust that, create a /desired/path/to/customjava.security file with the following content:

  securerandom.strongAlgorithms=NativePRNGNonBlocking:SUN
  

  • And then add the following to your JBoss JVM options (since this is a JVM option it needs to go in the .conf file rather than the .sh/.bat) to use this customized security property file and restart. This modification is then appended and applied on top of the JDK's default java.security file:

  -Djava.security.properties=/desired/path/to/customjava.security
  

  • If you already set a -Djava.security.properties file, then you can add the above line to your existing custom security properties file

Root Cause

• "/dev/random" hangs in java program when server is inactive
• The system is low on entropy. Moving from EAP 7.4 Update 14 to 7.4 Update 15 updates jsf-impl-2.3.14.SP07 to jsf-impl-2.3.14.SP08. This provides a new fix (Content from github.com is not included.MOJARRA_5375) to avoid exposure of the sessionid in the jfwid. To correct that, JSF now uses SecureRandom to generate a token seed for an app at start up. SecureRandom by default tries to generate random data based off system entropy from /dev/random. This is a blocking entropy source so if system entropy is too low to generate random data, the Java calls will block and wait for more system entropy.
• This content is not included.JBEAP-26824 - JSF token generation hangs EAP 7.4 Update 15 start up in low entropy environments

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.