reporter: support for async futures-based report() about rustracing_jaeger HOT 6 OPEN

@andrewbanchich

I think that it's somewhat dangerous to depend on tokio heavily because some users (including me) may want to use this crate outside of the asynchronous world (e.g., with the regular thread model). Besides, indeed, tokio seems a defact standard async runtime, but there are some alternatives (e.g., async-std) that provide its own channel implementation. Some user may want to use rustracing with one of the alternatives.

Instead of switching the channel implementation to tokio based one, IMO, it seems good to extend Tracer and SpanReceiver to allow arbitrary channel type as a type parameter (I have no plan to implement this feature in the near future though...).

By the way, just FYI, this crate now uses crossbeam as the channel implementation (see sile/rustracing#4).

from rustracing_jaeger.

It seems interesting to support futures. But currently, rustracing_jaeger (and rustracing) heavily depends on std::sync::mpsc, so it is difficalt to integrated with futures smoothly.

If your are not annoying to spawn a thread dedicated for the reporting, it will be easiest way to use the thread as follows:

let (tracer, span_rx) = Tracer::new(rustracing::sampler::AllSampler);

// Spawns a reporting thread at the initialization phase in your application
std::thread::spawn(move || {
    let mut reporter = track_try_unwrap!(JaegerCompactReporter::new("example"));
    while let Ok(span) = span_rx.recv() {
        if reporter.report(&[span][..]).is_err() {
            break;
        }
    }
});

// The operations of `tracer` are not blocked, so it can be used in asynchronous code.

from rustracing_jaeger.

@sile Any update on this? Rust has had async/await for a while now and you could use Tokio's mpsc instead of std's.

from rustracing_jaeger.

Instead of switching the channel implementation to tokio based one, IMO, it seems good to extend Tracer and SpanReceiver to allow arbitrary channel type as a type parameter

I tried implementing this idea in sile/rustracing#9. If you think this PR is good, I'll merge it. > @andrewbanchich

from rustracing_jaeger.

That makes sense to me.

I've actually just switched to using the official opentelemetry crate alongside tracing and tracing-opentelemetry.

Thank you though!

from rustracing_jaeger.

@andrewbanchich No problem! Thank you for letteing me know that.

from rustracing_jaeger.