Skip to content

Prevent Tomcat from blocking during startup due to eager session id generation #6174

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wilkinsona opened this issue Jun 16, 2016 · 0 comments
Assignees
Labels
type: enhancement A general enhancement
Milestone

Comments

@wilkinsona
Copy link
Member

wilkinsona commented Jun 16, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant