I will certainly give that a try and see what happens! Once we get a chance to make the change and observe, I'll report the results!
Something else we were looking through, regarding all this:
The class generating the stalls (GTConnect) is directly related to the UnifiedAcceptorRequestWrapper. Would it be possible to remove the stall tracer from the tracer group that is instrumenting the UnifiedAcceptorRequestWrapper and then reinstate the tracer for any other class being instrumented by name, and would doing so prevent the Stall tracer being run on the UnifiedAcceptorRequestWrapper?
My senior was walking me through the logs - it looks like the UnifiedAcceptorRequestWrapper is called here:
Processing class com/gtnet/httpClient/security/config/RequestURIConfig
Processing class com/gtnet/httpClient/security/config/GeneralErrorPage
Processing class com/gtnet/httpClient/security/config/Page
Processing class com/gtnet/httpClient/comms/AcceptorMode
Processing class com/gtnet/httpClient/comms/UnifiedAcceptorRequestWrapper
Processing class javax/servlet/http/HttpServletRequestWrapper
Processing class javax/servlet/ServletRequestWrapper
getInputStream:0 inserted method tracer object allocation: com/wily/introscope/agent/trace/hc2/DirectStreamAccessWatcherTracer
getReader:0 inserted method tracer object allocation: com/wily/introscope/agent/trace/hc2/DirectStreamAccessWatcherTracer
The Unified Acceptor Request Wrapper is being instrumented with the DirectStreamAccessWatcherTraces and is the only ServletRequestWrapper that is being instrumented within context of the Java Agent on this server.
Could we disable that tracer and change the definition to exclude the stalls?