I think this is an issue in support-core's custom log handler, and it seems related to
It looks like ReplayAction.ensurePermissionRegistered is being loaded, and during the load, it locks a class loader, and somewhere during the load after the class loader is locked, Jetty's class loader ends up writing to the logs, which is then handled by CustomHandler which tries to lock a StreamHandler.
At the same time, GitSCM.onLoaded tries to log an exception, which is also intercepted by CustomHandler. It locks the StreamHandler, and then the custom log handler uses SupportLogFormatter.format to format the message, but the formatter tries to load classes, which will require locking the same class loader that ReplayAction.ensurePermissionRegistered already locked, and so we have a deadlock.
Maybe preloading SupportLogFormatter here is not enough to preload PrintWriter and Throwable, so we should add them as well? Or maybe the class loaders have to be consulted even though the classes have already been loaded, and so this is just a really nasty timing bug.
Maybe it could be fixed by getting rid of the class loading in support-core's SupportLogFormatter (not sure how it would affect the behavior), or maybe the scope of the custom handler could be changed to exclude Jetty's class loader, and then we could install a separate log handler for Jetty that doesn't need to do anything fancy. I'm not sure what is causing GitSCM.onLoaded and ReplayAction.ensurePermissionRegistered to be called at the same time, but it looks like they are running as part of the Reactor during startup, and I think it is normal for it to execute things with no interdependency in parallel.
Andrew Feller Are you able to reproduce this consistently? Did you start seeing the error immediately after updating Jenkins or any plugins?