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.