While profiling an application that makes heavy use of RESTEasy client over Jetty, we noticed a large amount of time spent acquiring locks in the JarFile class.

It looks like each HTTP call we make is enqueued to a ContextualExecutor.

When the call begins, we end up at the line:

ServiceLoader.load(ThreadContext.class).forEach(context -> contexts.put(context, context.capture())); 

This scans the classpath, taking an exclusive lock in the process, at ZipFile.getEntry.

Is it possible that ContextualExecutor can load the set of ThreadContext providers more eagerly, perhaps on construction?

If this must dynamically change based on thread context class loader, would it instead be acceptable to cache the loaded ThreadContext providers, maybe in a WeakHashMap<ClassLoader, List<ThreadContext>>?

Thank you for considering this improvement.