ScopedValue.runWhere not returning scope

[Marcin Grzejszczak]

OK, but can we confirm some assumptions first?

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.

Pozdrawiam / Best regards,
Marcin Grzejszczak

https://marcin.grzejszczak.pl
https://toomuchcoding.com


pt., 7 cze 2024 o 15:39 robert engels <robaho at icloud.com> napisał(a):

> 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.
>
> If you don’t redesign the software to take advantage of VT then it won’t
> matter.
>
> 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.
>
> On Jun 7, 2024, at 10:15 AM, Marcin Grzejszczak <
> marcin.grzejszczak at gmail.com> wrote:
>
> 
> > 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.
>
> 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?".
>
> > If they are redesigning they can use an interceptor based solution that
> is designed for scoped variables.
>
> 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.
>
> Pozdrawiam / Best regards,
> Marcin Grzejszczak
>
> https://marcin.grzejszczak.pl
> https://toomuchcoding.com
>
>
> pt., 7 cze 2024 o 15:11 robert engels <robaho at icloud.com> napisał(a):
>
>> 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.
>>
>> If they are redesigning they can use an interceptor based solution that
>> is designed for scoped variables.
>>
>> On Jun 7, 2024, at 10:03 AM, Marcin Grzejszczak <
>> marcin.grzejszczak at gmail.com> wrote:
>>
>> 
>> > In AspectJ`s terms, interceptors such as these are equivalent to before
>> and after advice.
>>
>> Correct.
>>
>> > 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.
>>
>> 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.
>>
>> > If a design like this was deemed overkill before, perhaps its time has
>> arrived.
>>
>> 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?
>>
>> Pozdrawiam / Best regards,
>> Marcin Grzejszczak
>>
>> https://marcin.grzejszczak.pl
>> https://toomuchcoding.com
>>
>>
>> pt., 7 cze 2024 o 14:52 Pedro Lamarão <pedro.lamarao at prodist.com.br>
>> napisał(a):
>>
>>> Em sex., 7 de jun. de 2024 às 10:05, Marcin Grzejszczak <
>>> marcin.grzejszczak at gmail.com> escreveu:
>>>
>>>
>>>> > Can you explain that a little more? Why can't isolated functionality
>>>> be added without separate before and after logic?
>>>>
>>>> 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.
>>>>
>>>
>>> In AspectJ`s terms, interceptors such as these are equivalent to before
>>> and after advice.
>>> To enable something like a ScopedValueInterceptor, it seems to me
>>> sufficient to extend this scheme to include around advices.
>>> 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.
>>> If a design like this was deemed overkill before, perhaps its time has
>>> arrived.
>>>
>>> --
>>> Pedro Lamarão
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240610/338e3ae8/attachment.htm>