Consider a blacklist approach for RequestContextCurrentTraceContext

An armeria app uses a tracing object that coexists with activity that is not request originated. Threads like these will result in the following message to be logged:

                logger.warn("Attempted to propagate trace context, but no request context available. " +
                            "Did you forget to use RequestContext.contextAwareExecutor() or " +
                            "RequestContext.makeContextAware()?", new NoRequestContextException());

The advice is totally invalid in these cases as for example a scheduled thread or reporting loop has no relevance (afaik).

One way out is to allow configuration of a pattern of threads that should be ignored as opposed to spawning this message. This will allow options besides wild hacks or worse killing the log message.

Ex this is how sleuth handles one of the places that are relatively hard to shut-up 😃 https://github.com/spring-cloud/spring-cloud-sleuth/blob/558900155adb1ae4a732cf450c216e2ff04a3f90/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/rxjava/SleuthRxJavaSchedulersHook.java#L126

Another option is to introduce some sort of thread local which you can set to say “ignore”. For example, I could set that in a thread factory in order to quiet the root thing I’m trying to do which is in some ways better than scary comments which may end up lying.

thoughts?

[codefromthecrypt]

I agree it is worthwhile thinking through, if nothing else for brave 6. There have been cases especially around propagation policy (like which headers… which is different than in-process) that need some rethought eventually. However, at the moment, trying to add a hook to the span about how you will look the same span up ends up contortionist I think (as currently any hints we store are inside the data in the thread local which we are currently discussing 😛). That said each instrumentation could choose to do things differently, but we sortof already do because we never use thread locals in our code except crazy circumstances. regardless, feel free to raise a discussion on brave. tx!

[anuraaga]

Yeah think we can discuss here, just wondering if it makes sense to add the switching mechanism in Brave. Allowing threads to opt-out of the warning handles many use cases, but still stuck for my database threadpool since it’s used both during request handling and also in the background with things like SET charset. Being able to specify the trace context propagation method when starting a trace, instead of globally, would help with that.