Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

[forax at univ-mlv.fr]

> De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 9 Avril 2021 17:41:28
> Objet: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> That's the thing, I'm not using an agent. We're doing the wrapping at runtime by
> instrumenting spring beans.

Apart the fact that decorateTask is a good example of why it's better to use delegation than using the template method pattern. 
Why do you need to call decorateTask() directly, and not execute/submit/invoke with your wrapped Runnable ? 

Rémi 

> Pobierz aplikację [ https://aka.ms/o0ukef |
> Outlook dla systemu iOS ]

> Od: Remi Forax <forax at univ-mlv.fr>
> Wysłane: Friday, April 9, 2021 5:18:11 PM
> Do: Marcin Grzejszczak <mgrzejszczak at vmware.com>
> DW: core-libs-dev <core-libs-dev at openjdk.java.net>
> Temat: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
> ----- Mail original -----
> > De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> > À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoyé: Vendredi 9 Avril 2021 16:29:32
> > Objet: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> > Hi!

> > I'm the lead of Spring Cloud Sleuth [1], a project dedicated to working with
> > distributed tracing. We're propagating the tracing context e.g. through
> > threads. That means that when a user spawns a new thread we need to pass the
> > context from the old thread to the new one. Example - if the user uses an
> > Executor or an ExecutorService (e.g. via calling the execute(Runnable r)
> > method) then we need to wrap the Runnable in its trace representation. That
> > means that we retrieve the context from Thread A , pass it in the constructor
> > of the TraceRunnable and then restore it once the run method is called in
> > Thread B.

> > The problem in Sleuth that we have with JDK16 is that we can't use reflection to
> > ensure that we're wrapping all methods of any Executors [2]. In other words we
> > want to create a proxy around an existing Executor and wrap all methods.
> > Currently, we're using reflection cause Executor implementations such as
> > `ScheduledThreadPoolExecutor` have quite a few protected methods that we can't
> > access. What we would like to achieve is a delegation mechanism that we can
> > wrap all objects that the given Executor is using within their API (such as
> > Runnables, Callables, other Executors) in their trace representation and then
> > delegate calls for all methods to the wrapped object. That would also mean the
> > delegation to currently protected methods.

> > If there's another way to achieve this other than opening the
> > java.util.concurrent API then I would very much like to use it. Currently with
> > JDK16 it's not possible to instrument that code so context propagation might be
> > buggy when dealing with executors.

> I'm not sure if you are using an agent or not, if you are using an agent, you
> can redefine a module
> [
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&data=04%7C01%7Cmgrzejszczak%40vmware.com%7Cc45688f3edb8423b9cae08d8fb6ab28a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637535782975891768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=RHHLZTpU5RMNx7JHwkgG79%2FHWlXsXYOG8bBw9WaYQCU%3D&reserved=0(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map
> |
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&data=04%7C01%7Cmgrzejszczak%40vmware.com%7Cc45688f3edb8423b9cae08d8fb6ab28a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637535782975891768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=RHHLZTpU5RMNx7JHwkgG79%2FHWlXsXYOG8bBw9WaYQCU%3D&reserved=0(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map
> ] )

> regards,
> Rémi


> > Marcin Grzejszczak
> > Staff Engineer, Spring Cloud