<div dir="ltr"><div>OK, but can we confirm some assumptions first? </div><div><br></div><div>Do I understand correctly that ScopedValues will be significantly faster than Thread Locals? If that's the case just by returning a Scope object instead of expecting a lambda all the tracing libraries and all instrumentations that are out there will not need a major redesign. I think that it's worthwhile to consider such an option in that scenario.<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Pozdrawiam / Best regards,</div><div>Marcin Grzejszczak</div><div><br><div><a href="https://marcin.grzejszczak.pl" target="_blank">https://marcin.grzejszczak.pl</a></div><div><a href="https://toomuchcoding.com" target="_blank">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 7 cze 2024 o 15:39 robert engels <<a href="mailto:robaho@icloud.com">robaho@icloud.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">My understanding is that the only performance downside to TL is due to the sheer number of threads possible vs a platform thread solution. Most likely existing tracing solutions are not designed to support this anyway - it would orders of magnitude more tracing information to track and disseminate. If the tracing solution already supports high volume async requests it’s doubtful it uses TL based solutions as the would be needless overhead. </div><div dir="ltr"><br></div><div dir="ltr">If you don’t redesign the software to take advantage of VT then it won’t matter.  </div><div dir="ltr"><br></div><div dir="ltr">I expect someone will design a VT optimized tracing solution though. I also expect the TL based solutions will still work though - maybe not optimally. </div><div dir="ltr"><br><blockquote type="cite">On Jun 7, 2024, at 10:15 AM, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" target="_blank">marcin.grzejszczak@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>> I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. <br></div><div><br></div><div>Let me quote one of my previous replies: "I mean if there's no distinction in terms of performance between Scoped Values and Thread Locals then we should just need to ensure that there's an interop between Thread Locals and Scoped Values and current implementations could stay on Thread Locals. But I thought that the very idea is to use Scoped Values preferably with Virtual Threads to have best performance in comparison to using Thread Locals. Maybe I made a mistake in this assumption?". <br></div><div><br></div><div>> If they are redesigning they can use an interceptor based solution that is designed for scoped variables. <br></div><div><br></div><div>That would require a lot of libraries to redesign their API. I'm not saying this is a bad thing but that might be a lot of work on many different projects. Also some libraries will migrate, some won't so there needs to be an interop between TL and SV.<br></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Pozdrawiam / Best regards,</div><div>Marcin Grzejszczak</div><div><br><div><a href="https://marcin.grzejszczak.pl" target="_blank">https://marcin.grzejszczak.pl</a></div><div><a href="https://toomuchcoding.com" target="_blank">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 7 cze 2024 o 15:11 robert engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. </div><div dir="ltr"><br></div><div dir="ltr">If they are redesigning they can use an interceptor based solution that is designed for scoped variables. </div><div dir="ltr"><br><blockquote type="cite">On Jun 7, 2024, at 10:03 AM, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" target="_blank">marcin.grzejszczak@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>> In AspectJ`s terms, interceptors such as these are equivalent to before and after advice.</div><div><br></div><div>Correct.<br></div><div><br></div><div>> To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advice. The handler of AroundInterceptors would pass a proceed object to the around advice. ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope.</div><div><br></div><div>Agreed. For this scenario preferably one could use the around advice. That's in the case of an ideal solution where all projects are green fields. But we're not in such a state.<br></div><div><br></div><div>> If a design like this was deemed overkill before, perhaps its time has arrived.<br><br></div><div>I wonder if the solution that the library maintainers should be required to migrate to a new design is the proper one. I've only listed 8 projects that Micrometer Observation instruments but I'm pretty sure that there are more. I wonder if such an ask to redesign the API wouldn't be an overkill?<br></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Pozdrawiam / Best regards,</div><div>Marcin Grzejszczak</div><div><br><div><a href="https://marcin.grzejszczak.pl" target="_blank">https://marcin.grzejszczak.pl</a></div><div><a href="https://toomuchcoding.com" target="_blank">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 7 cze 2024 o 14:52 Pedro Lamarão <<a href="mailto:pedro.lamarao@prodist.com.br" target="_blank">pedro.lamarao@prodist.com.br</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Em sex., 7 de jun. de 2024 às 10:05, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" target="_blank">marcin.grzejszczak@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> Can you explain that a little more? Why can't isolated functionality be added without separate before and after logic?<br></div><div><br></div><div>I mentioned that above but I'll try to rephrase it. There are already solutions such as Apache CXF [1], Apache Commons for Http client [2], Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such interceptors. All that code would have to be rewritten. I'm not saying that this is not feasible but let's be realistic. Also if all of those libraries wouldn't rewrite their code then distributed tracing would be broken. If one service is not working then instead of one correlation you will get two or more.</div></div></blockquote></div><div><br></div><div>In AspectJ`s terms, interceptors such as these are equivalent to before and after advice.</div><div>To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advices.</div><div>The handler of AroundInterceptors would pass a proceed object to the around advice.</div><div>ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope.</div><div>If a design like this was deemed overkill before, perhaps its time has arrived.</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>
</blockquote></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></div></blockquote></div>