ScopedValue.runWhere not returning scope

[Robert Engels]

I updated the github.com/robaho/scope_trace <http://github.com/robaho/scope_trace> code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine.

The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. 

Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 <https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39>

This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open).

Notice also 

Span span = ThreadLocalSpan.CURRENT_TRACER.next();

This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don’t see how adding open/close to ScopedValue values would alleviate this.

I am guessing most libraries have these hard-coded dependencies on ThreadLocal.

Thus, someone will write a VirtualThread/ScopedValue “native” tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don’t think that is the case - as it will generate a lot of noise.

“scope values” are not only for tracing scopes.


> On Jun 17, 2024, at 7:01 AM, robert engels <robaho at icloud.com> wrote:
> 
> Your statements like “a user puts a scope in a SV won’t be honored”. Of course not. I think you are trying to conflate scoped values with tracing scopes. They are not the same thing and can’t be treated as such due to the volume. 
> 
> The user will manage scopes for tracing the way they do now. It is an implementation detail on how the tracing library manages these scopes. They currently use thread locals. As I’ve pointed out several times the library can use a scoped value to carry the scope context - and mange the active scopes within in 
> 
> You are trying to make the scoped values be able to support tracing directly. I don’t believe that was ever a design goal. 
> 
>> On Jun 17, 2024, at 5:59 AM, Marcin Grzejszczak <marcin.grzejszczak at gmail.com> wrote:
>> 
>> 
>> > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems.
>> 
>> Can you elaborate please?
>> 
>> Pozdrawiam / Best regards,
>> Marcin Grzejszczak
>> 
>> https://marcin.grzejszczak.pl <https://marcin.grzejszczak.pl/>
>> https://toomuchcoding.com <https://toomuchcoding.com/>
>> 
>> czw., 13 cze 2024 o 19:23 Andrew Haley <aph-open at littlepinkcloud.com <mailto:aph-open at littlepinkcloud.com>> napisał(a):
>> On 6/13/24 16:03, Robert Engels wrote:
>> > 3. More importantly, if you use VT effectively, you are talking about
>> > orders of magnitude more “trace contexts” (in the default brave handler
>> > they are shared by thread so they are highly limited since the only
>> > effective Java threading implementation prior to VT required pooled
>> > threads) which reinforces my point about the increase in the volume of
>> > unique data is the major problem for existing tracing libraries, which
>> > will probably require architectural changes anyway.
>> 
>> Definitely, yes. If you need to create a context for every virtual thread,
>> scoped values versus thread-local variables is the least of your problems.
>> 
>> -- 
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com <https://www.redhat.com/>>
>> https://keybase.io/andrewhaley <https://keybase.io/andrewhaley>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240617/596858b1/attachment-0001.htm>