opentracing-contrib / java-concurrent Goto Github PK

OpenTracing-aware helpers related to java.util.concurrent

License: Apache License 2.0

Java 84.77% Shell 15.23%

opentracing tracing concurrent-programming executorservice runnable callable

java-concurrent's Introduction

OpenTracing instrumentation for `java.util.concurrent`

OpenTracing instrumentation for java.util.concurrent package. It instruments ExecutorService, Executor, Runnable and Callable.

Configuration

ExecutorService executorService = new TracedExecutorService(Executors.newFixedThreadPool(4), tracer);

Development

./mvnw clean install

Release

Follow instructions in RELEASE

java-concurrent's People

Contributors

Stargazers

Watchers

Forkers

pavolloffay kameshsampath objectiser debmalya jpkrohling jam01 archer-christ tsipo malafeev misselvexu atomictag xyslion berrytea billibit kohegen isabella232 vincer bulksecuritygeneratorprojectv2

java-concurrent's Issues

ClassCastException with Slick

I am using OpenTracing Special Agent with Play and Slick. If I include the "concurrent" rule, I get the following error with Slick.

[error] ErrorHandler - class io.opentracing.contrib.specialagent.rule.concurrent.TracedRunnable cannot be cast to class slick.util.AsyncExecutor$PrioritizedRunnable (io.opentracing.contrib.specialagent.rule.concurrent.TracedRunnable is in unnamed module of loader 'bootstrap'; slick.util.AsyncExecutor$PrioritizedRunnable is in unnamed module of loader play.runsupport.NamedURLClassLoader @70355caa)
java.lang.ClassCastException: class io.opentracing.contrib.specialagent.rule.concurrent.TracedRunnable cannot be cast to class slick.util.AsyncExecutor$PrioritizedRunnable (io.opentracing.contrib.specialagent.rule.concurrent.TracedRunnable is in unnamed module of loader 'bootstrap'; slick.util.AsyncExecutor$PrioritizedRunnable is in unnamed module of loader play.runsupport.NamedURLClassLoader @70355caa)
	at slick.util.ManagedArrayBlockingQueue.offer(ManagedArrayBlockingQueue.scala:17)
	at java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1347)
	at slick.util.AsyncExecutor$$anon$1$$anon$4.execute(AsyncExecutor.scala:163)
	at slick.basic.BasicBackend$DatabaseDef.runSynchronousDatabaseAction(BasicBackend.scala:265)
	at slick.basic.BasicBackend$DatabaseDef.runSynchronousDatabaseAction$(BasicBackend.scala:263)

Looks like it is trying to instrument something it shouldn't. If this issue should be part of the Special Agent instead, please let me know.

If I don't include the concurrent plugin, there are no errors. But then the tracer is not propagated properly.

Can you show some scenarios when to using java-concurrent tracing？

Can you show some scenarios use this library. Thank you very much.

The trace context does not propagate to the callback of ThreadPoolTaskExecutor/Scheduler

TracedThreadPoolTaskExecutor tracedExecutor = new TracedThreadPoolTaskExecutor(myExecutor, GlobalTracer.get());
try (Scope scope = GlobalTracer.activateSpan(span)) {
    ListenableFuture<?> future = tracedExecutor.submitListenable(() -> {
        Thread.sleep(1000); // Let callback run in other thread
        System.out.println(GlobalTracer.get().activeSpan()); // It's OK
    });
    future.addCallback(
        r -> System.out.println(GlobalTracer.get().activeSpan()), // Context loss!
        e -> {}
    );
}

It's confusing me, the context (activeSpan) is loss in the callback while the main task can get it correctly.

exceptions are not logged

Is there a reason that exceptions are not added to spans?

Can byteman be used to automatically wrap executors?

This is a bit of a sprawling question, but wrapping all executors in a TracedExecutorService is quite intrusive. Is there a means to have byteman recognize an applicable situation and wrap the call?

Create new span if paren span is missing

This library currently, only passes active span from parent thread to submitted runnable/callable. If there is no parent span it does nothing.

We should consider creating a new span if there is no parent span.

ongoing span relationships with jobs that repeat jobs

It seems questionable to propagate the parent span to jobs (callables and runnables) that repeat forever. This leads to traces that never close.

I have a use case where a first-access causes a scheduled job to be created 'scheduleAtFixedRate' or 'scheduleWithFixedDelay'. This is a repeated job, as such, it should not be associated with the parent span that initially caused it to be scheduled.

This behavior is in the TracedScheduledExecutorService class. I would suggest that inclusion of the these 'rules' be opt-in, not by default.

I'm curious what the use case is of associating a repeating job with a parent span, as I can't think of one immediately...

Additional documentation

The readme says this package instruments ExecutorService, Executor, Runnable, and Callable, but it only gives an example for ExecutorService. Is the only entry point ExecutorService? Or is there something you would do to directly instrument Executor, Runnable, and Callable?

Also, I'm wondering how these calls will be show up when looking at the trace. E.g. Parseq tracing does a really good job at showing you the line number and method where each span occurred. Does this package have any ability to appropriately name each span automatically or to allow the user to create their own name for each span? It would be really helpful to see what a trace using this package looks like

use TracedExecutorService occur OOM

we used TracedExecutorService occur oom when service run long time with high throughput
code ：

jvm dump analyze ：

Instrumenting ForkJoinPool

An issue on java-opentracing was referenced on java-specialagent.

Quoting @yurishkuro:

Are there plans for monkey-patching ForkJoinPool's common pool? Without that stream APIs don't propagate the context, unless a custom executor is used which leads to much uglier code (and is easy to forget).

How to pass parent context with TracedExecutor Service

currently the traced executor service - creates new spans, wondering is there a way we can extend it to use parentSpanContext if any, typically used in Chaining scenarios.