Hi jperkins-rhn , we are continuing to profile our resteasy client app and I think I found one more bottleneck. We currently run 6.2.2 + https://github.com/resteasy/resteasy/pull/3395 + https://github.com/resteasy/resteasy/pull/3418 (I didn't see any other issues fixed in 6.2.3 that seemed related, so we haven't patched that one yet, were hoping to wait for 6.3.0...)

It seems that in most cases, we now do not have to do a classpath scan when submitting a request. However, it still shows up in our profile trace, just much less often:

It seems that when we are already in a ContextualExecutorService wrapped Runnable, running on the shared async pool, which then tries to execute a new context-wrapped task back into the pool, we still end up scanning the classpath. I think this means that we got null back from ResteasyProviderFactory.getInstance().getContextData(ThreadContexts.class)

and }}therefore have to look up a{{{} {{new ThreadContexts(){}}}.

Is it possible that somehow the ContextualExecutor is propagating thread context, but not the fast-path to then propagate the context again from within a wrapped runnable? We do provide a custom executor through ResteasyClientBuilderImpl.executorService. I apologize for our weird patched build - if you think there's some hope 6.2.3 would make a difference I can apply our jetty changes and re-test. Thank you for your thoughts!