Description
By default, Tomcat forces the generation of a session id during startup to ensure that a SecureRandom instance has been initialized. When there is a lack of entropy (as is often the case on a newly booted VPS, for example) this can block for a long time (several minutes in some cases) causing users to incorrectly believe that their application has hung during startup. This is particularly problematic for applications that don't use HTTP sessions as they are paying the startup cost for no benefit.
Undertow takes a different approach by performing all session id generation on demand. The trade off is that the first request that requires a session will be very slow while the SecureRandom is initialized. However, something very similar can happen with Tomcat. It uses a queue of SecureRandom instances. Whenever the queue is empty, a new SecureRandom is created, initialized, used, and added to the queue. If entropy is low, this will block a request. The queue may be empty whenever multiple requests generate a session ID concurrently.
The simple solution is to subclass StandardSessionIdGenerator and override startInternal so that it doesn't call generateSessionId. A slightly more complicated solution would be to implement the simple solution and also add something to BackgroundPreinitializer to call getSessionId() on our custom SessionIdGenerator asynchronously. The more complicated solution has the downside of always initialising a SecureRandom even though an application may not need it. Given that we have had no complaints about Undertow's behaviour, I am in favour of implementing the simple solution.