You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ofSecureRandom
instances. Whenever the queue is empty, a newSecureRandom
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 overridestartInternal
so that it doesn't callgenerateSessionId
. A slightly more complicated solution would be to implement the simple solution and also add something toBackgroundPreinitializer
to callgetSessionId()
on our customSessionIdGenerator
asynchronously. The more complicated solution has the downside of always initialising aSecureRandom
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.The text was updated successfully, but these errors were encountered: