Some executors cannot handle tasks that have been wrapped into
`{Runnable,Callable}Wrapper` because they require certain subclass of
`{Callable,Runnable}` in order to work. We have a test that
effectively disables instrumentation for such executors.
This change makes sure that tasks that do not need to be
wrapped (which essentially means anything that is not lambda) still
get traced in such executors. One notable example of affected executor
type is `ScheduledThreadPoolExecutor`.
This will allow better metric collection and identification of trends for individual services/hosts.
This is not enabled by default because it can result in a high cardinality of services.
Disable JIT in Java7 for 1 Bytebuddy method. Hopefully this will help
with this error:
```
Stack: [0x00007f892f079000,0x00007f892f17a000], sp=0x00007f892f174e30, free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x73db30] PhaseIdealLoop::build_loop_late_post(Node*)+0x130
V [libjvm.so+0x73e06b] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x10b
V [libjvm.so+0x745239] PhaseIdealLoop::build_and_optimize(bool, bool)+0x899
V [libjvm.so+0x4589b0] Compile::Optimize()+0x8f0
V [libjvm.so+0x459e87] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool)+0x10c7
V [libjvm.so+0x3c9c5c] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xec
V [libjvm.so+0x45f5bb] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x32b
V [libjvm.so+0x460960] CompileBroker::compiler_thread_loop()+0x440
V [libjvm.so+0x9283ab] JavaThread::thread_main_inner()+0xdb
V [libjvm.so+0x928590] JavaThread::run()+0x1d0
V [libjvm.so+0x7f56e2] java_start(Thread*)+0x122
Current CompileTask:
C2: 3653 733
net.bytebuddy.description.type.TypeDescription$Generic$Visitor$Substitutor::onParameterizedType (129
bytes)
```
Not doing this seems to cause issues with Clojure protocols.
An application instrumented with the dd-java-agent that will
otherwise run fine will fail with ClassNotFoundException for
classes pertaining to Clojure protocols.
Some applications set java.util.logging.manager but never actually initialize the logger.
Check to see if the configured manager is on the system classpath.
If so, it should be safe to initialize jmxfetch which will setup the log manager.
Some applications seem to have this jboss class on the classpath, but don’t actually use it. When coupled with not actually using JUL, this means that we may never actually start JMXFetch.
Checking for JBOSS_HOME instead should be safer.
Nikolay Martynov
Tyler Benson
Tyler Benson
Daniel Solano Gómez
Will Gittoes
Will Gittoes