Creating a dependency on ExecutorInstrumentation

Elastic Observability APM
1

Friends,

I've written a couple of simple plugins to cover some unsupported cases in legacy code.

I'm considering another such case where all I really need is to extend co.elastic.apm.agent.concurrent.ExecutorRunnableInstrumentation and change the getTypeMatcher method.

Is this a reasonable dependency or should I consider ExecutorRunnableInstrumentation to be an implementation detail that I should not rely on?

thanks

2

Hi,

Can you elaborate a bit on the unsupported cases in legacy code here ?

Generally speaking it's tricky to have cross-instrumentation dependencies, and maybe there are alternative ways than directly depending on instrumentation implementation details.

3

For the new case I have in mind, a team took the old util.concurrent library, renamed the packages, and added it to their own codebase. Supporting transferring the trace context across threads would be exactly like the agent does for java.util.concurrent except the package names are different.

4

In this case then it's probably better to just duplicate the existing instrumentation for java.util.logging and package it as an external plugin.

You could also maintain your own fork of the agent as well for this, as this won't be a common use-case.

As a side note, having to duplicate code from java.util.concurrent really seems like an anti-pattern for future maintenance:

  • you will have to maintain this duplicated code over time and won't benefit from JVM enhancements in this area unless you keep up with it
  • you will have to maintain your own instrumentation of fork for supporting it