| Thank you Craig Lutgen for the report. Due to the stack trace, the symptoms are different from JENKINS-55070. Here the problem is revealed in AuthorizationContainer.java#L169. After a deeper investigation, the problem seems to be after the nullification of theInstance in Jenkins#L3400. There is a moment between the instance being null and the real restart (fraction of second) and that that time, the instance cannot be retrieved. As the HudsonIsRestarting is only used as the last filter, it has no chance to avoid other computation yet. The problem is when a filter that is applied earlier, requires to have access to Jenkins.get(). I see two opportunities to correct the problem:
- Ensure every filter or class being potentially used by a filter, to not use Jenkins.get(), but instead Jenkins.getInstanceOrNull() and act correctly in case it's null. This could require a lots of work and hard time explaining the situation to people.
- Prevent the regular filters to be applied when the HudsonIsRestarting is the "app" in the servletContext.
To elaborate on option 2, current flow of filters to servlet:
- DiagnosticThreadNameFilter
- CharacterEncodingFilter
- CompressionFilter
- HudsonFilter
- ChainedServletFilter
- HttpSessionContextIntegrationFilter2
- BasicHeaderProcessor
- AuthenticationProcessingFilter2
- RememberMeProcessingFilter
- AnonymousProcessingFilter
- ExceptionTranslationFilter
- UnwrapSecurityExceptionFilter
- CrumbFilter
- PluginServletFilter
- UserLanguages
- [...] << PluginServletFilter.addFilter (mainly for legacy plugins)
- Stapler as the main Servlet
We could either bypass completely the filter and reach directly the app, or disabling the configured filters. If we bypass the rest of the filter, we will have troubles to deliver the asset bounded to the restart page, but this could be done "inline" and avoid any other parallel call. That could solve the
| 
