Thread Locals (was Re: State of Loom)

[Alen Vrečko]

I want to display application level request information on status page for
each thread in the thread pool. I want to see that Thread #1 is processing
request /foo with session bar coming from ip baz on the server status page.

Currently this is a one liner: map.put(Thread.currentThread(), requestInfo)
and a one liner to query the info.

With access to carrier thread. I can migrate to loom with a one liner
change: map.put(LoomUtil.currentCarrierThread(), requestInfo).

To do it your way. If I understand correctly. I'd need to write a custom
scheduler. In order for my http request processor virtual threads  to tell
the scheduler the session id it is processing. I need a custom runnable
interface that supplies an object for communication and pass it along the
call chain or alternatively the virtual request processor threads could
have a property for the request info object?

What is the minimum amount of code to get this done without access to
carrier thread?

How will you prevent reflective access?

Best regards
Alen

V V čet., 28. maj 2020 ob 18:43 je oseba Ron Pressler <
ron.pressler at oracle.com> napisala:

> Can you explain your use case? We have some ideas and will make
> some suggestions, perhaps encapsulated as a new core libraries construct,
> but the more we know about which use-cases cause particular pain, the
> better we can address them.
>
> But let me be clear: the carrier will *not* be accessible by reflection.
> The base
> module will be closed to deep reflection by default before Loom is
> delivered.
>
> — Ron
>
>
> On 28 May 2020 at 15:04:19, Alen Vrečko (alen.vrecko at gmail.com) wrote:
>
> Some of us will just use reflection to get the carrier thread.
>
> When I went trough the production code and made it play nice with loom. In
> most cases I could find nicer alternatives to TL usage. There aren't many
> TLs being used anyway. But in one particular case I just gave up. The
> alternative is rather involved and in my view convoluted. I opted to get
> the carrier thread reference via reflection and used it to make
> effectively
> a TL. Simple and it got the job done.
>
> It might be a good compromise. Find alternatives to TLs. But if there are
> no good alternatives, here is a reference to carrier tread, use it at your
> own risk.
>
> Alen
>
>