<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I updated the <a href="http://github.com/robaho/scope_trace" class="">github.com/robaho/scope_trace</a> code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine.<div class=""><br class=""></div><div class="">The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. </div><div class=""><br class=""></div><div class="">Again referring to brave, look at <a href="https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39" class="">https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39</a></div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Notice also </div><div class=""><br class=""></div><div class="">Span span = ThreadLocalSpan.CURRENT_TRACER.next();</div><div class=""><br class=""></div><div class="">This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. <b class="">I don’t see how adding open/close to ScopedValue values would alleviate this.</b></div><div class=""><br class=""></div><div class="">I am guessing most libraries have these hard-coded dependencies on ThreadLocal.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">“scope values” are not only for tracing scopes.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 17, 2024, at 7:01 AM, robert engels <<a href="mailto:robaho@icloud.com" class="">robaho@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">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 </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">You are trying to make the scoped values be able to support tracing directly. I don’t believe that was ever a design goal. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jun 17, 2024, at 5:59 AM, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" class="">marcin.grzejszczak@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">> 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.</div><div class=""><br class=""></div><div class="">Can you elaborate please?<br class=""></div><div class=""><br class=""></div><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Pozdrawiam / Best regards,</div><div class="">Marcin Grzejszczak</div><div class=""><br class=""><div class=""><a href="https://marcin.grzejszczak.pl/" target="_blank" class="">https://marcin.grzejszczak.pl</a></div><div class=""><a href="https://toomuchcoding.com/" target="_blank" class="">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 13 cze 2024 o 19:23 Andrew Haley <<a href="mailto:aph-open@littlepinkcloud.com" class="">aph-open@littlepinkcloud.com</a>> napisał(a):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/13/24 16:03, Robert Engels wrote:<br class="">
> 3. More importantly, if you use VT effectively, you are talking about<br class="">
> orders of magnitude more “trace contexts” (in the default brave handler<br class="">
> they are shared by thread so they are highly limited since the only<br class="">
> effective Java threading implementation prior to VT required pooled<br class="">
> threads) which reinforces my point about the increase in the volume of<br class="">
> unique data is the major problem for existing tracing libraries, which<br class="">
> will probably require architectural changes anyway.<br class="">
<br class="">
Definitely, yes. If you need to create a context for every virtual thread,<br class="">
scoped values versus thread-local variables is the least of your problems.<br class="">
<br class="">
-- <br class="">
Andrew Haley (he/him)<br class="">
Java Platform Lead Engineer<br class="">
Red Hat UK Ltd. <<a href="https://www.redhat.com/" rel="noreferrer" target="_blank" class="">https://www.redhat.com</a>><br class="">
<a href="https://keybase.io/andrewhaley" rel="noreferrer" target="_blank" class="">https://keybase.io/andrewhaley</a><br class="">
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div></div></blockquote></div><br class=""></div></body></html>