I'm decorating existing user or framework code. If they have custom behavior, i want to respect that instead of override it.
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: fo...@univ-mlv.fr <fo...@univ-mlv.fr> Sent: Friday, April 9, 2021 6:33:10 PM To: Marcin Grzejszczak <mgrzejszc...@vmware.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16 ________________________________ De: "Marcin Grzejszczak" <mgrzejszc...@vmware.com> À: "Remi Forax" <fo...@univ-mlv.fr> Cc: "core-libs-dev" <core-libs-dev@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ę Outlook dla systemu iOS<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=04%7C01%7Cmgrzejszczak%40vmware.com%7C945386adac8e497074c408d8fb752d00%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637535827988392448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BHiUJZH2bfIaGb30vvz%2BxrA%2B1IObAnEKLqIbwBBjl%2BM%3D&reserved=0> ________________________________ Od: Remi Forax <fo...@univ-mlv.fr> Wysłane: Friday, April 9, 2021 5:18:11 PM Do: Marcin Grzejszczak <mgrzejszc...@vmware.com> DW: core-libs-dev <core-libs-dev@openjdk.java.net> Temat: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16 ----- Mail original ----- > De: "Marcin Grzejszczak" <mgrzejszc...@vmware.com> > À: "core-libs-dev" <core-libs-dev@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%7C945386adac8e497074c408d8fb752d00%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637535827988397428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OdUeAdV0it0JJfr%2FFQB4fc02EYlAfVXQkCX8vdgTx2Y%3D&reserved=0>) regards, Rémi > > Marcin Grzejszczak > Staff Engineer, Spring Cloud
