Structured concurrency in Java 19+

[Matt Sicker <bo...@gmail.com>]

Java 19 is coming out soon, and that includes a preview version of virtual threads and structured concurrency APIs. While I’m not that familiar with the Java implementation, I’d imagine it’ll have some similarities with Kotlin coroutines and other similar structured concurrency libraries.

I’ve played around with the general concept myself, particularly an interesting Python library for the same. I think some sort of structured concurrency architecture would be useful for making some async aspects of Log4j easier to understand (mostly the areas where we spawn threads for things, not for async logging). While the API isn’t stable, we can abstract it well enough with multi version jars. What I’m more curious about is how we’d interact (if at all) with virtual threads, coroutines, or structured concurrency APIs in general. If an app uses structured concurrency throughout, it might want the logging system to participate in the same flow for clean shutdowns.

Does anyone have any more concrete use cases that might be relevant for us? Or does this seem more relevant for networking libraries and frameworks?

—
Matt Sicker

Re: Structured concurrency in Java 19+

[Ralph Goers <ra...@dslextreme.com>]

The brief read of https://openjdk.org/jeps/425 I did suggested that the major difference between Virtual Threads and Platform Threads is that Virtual Threads should not be pooled. So the only changes we would need to make would be to use a Virtual Thread Executor. However, it probably will simplify the logic a bit as we now determine how big the pool size should be and now we won’t have to - every request will just get its own.

Ralph

> On Sep 7, 2022, at 11:40 AM, Matt Sicker <bo...@gmail.com> wrote:
> 
> Java 19 is coming out soon, and that includes a preview version of virtual threads and structured concurrency APIs. While I’m not that familiar with the Java implementation, I’d imagine it’ll have some similarities with Kotlin coroutines and other similar structured concurrency libraries.
> 
> I’ve played around with the general concept myself, particularly an interesting Python library for the same. I think some sort of structured concurrency architecture would be useful for making some async aspects of Log4j easier to understand (mostly the areas where we spawn threads for things, not for async logging). While the API isn’t stable, we can abstract it well enough with multi version jars. What I’m more curious about is how we’d interact (if at all) with virtual threads, coroutines, or structured concurrency APIs in general. If an app uses structured concurrency throughout, it might want the logging system to participate in the same flow for clean shutdowns.
> 
> Does anyone have any more concrete use cases that might be relevant for us? Or does this seem more relevant for networking libraries and frameworks?
> 
> —
> Matt Sicker

Re: Structured concurrency in Java 19+

[Matt Sicker <bo...@gmail.com>]

Scoped variables are a great example! There’s a similar concept in some reactive streams APIs (which is also a standard Java API starting in 9) with “contexts”, and the same concept is also available in the standard Go library in its “context” package for associating arbitrary values with string keys.
—
Matt Sicker

> On Sep 9, 2022, at 02:00, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> I expect scoped variables that will be introduced with Loom to replace MDC
> attached to threads.
> 
> On Wed, Sep 7, 2022 at 8:41 PM Matt Sicker <bo...@gmail.com> wrote:
> 
>> Java 19 is coming out soon, and that includes a preview version of virtual
>> threads and structured concurrency APIs. While I’m not that familiar with
>> the Java implementation, I’d imagine it’ll have some similarities with
>> Kotlin coroutines and other similar structured concurrency libraries.
>> 
>> I’ve played around with the general concept myself, particularly an
>> interesting Python library for the same. I think some sort of structured
>> concurrency architecture would be useful for making some async aspects of
>> Log4j easier to understand (mostly the areas where we spawn threads for
>> things, not for async logging). While the API isn’t stable, we can abstract
>> it well enough with multi version jars. What I’m more curious about is how
>> we’d interact (if at all) with virtual threads, coroutines, or structured
>> concurrency APIs in general. If an app uses structured concurrency
>> throughout, it might want the logging system to participate in the same
>> flow for clean shutdowns.
>> 
>> Does anyone have any more concrete use cases that might be relevant for
>> us? Or does this seem more relevant for networking libraries and frameworks?
>> 
>> —
>> Matt Sicker

Re: Structured concurrency in Java 19+

[Volkan Yazıcı <vo...@yazi.ci>]

I expect scoped variables that will be introduced with Loom to replace MDC
attached to threads.

On Wed, Sep 7, 2022 at 8:41 PM Matt Sicker <bo...@gmail.com> wrote:

> Java 19 is coming out soon, and that includes a preview version of virtual
> threads and structured concurrency APIs. While I’m not that familiar with
> the Java implementation, I’d imagine it’ll have some similarities with
> Kotlin coroutines and other similar structured concurrency libraries.
>
> I’ve played around with the general concept myself, particularly an
> interesting Python library for the same. I think some sort of structured
> concurrency architecture would be useful for making some async aspects of
> Log4j easier to understand (mostly the areas where we spawn threads for
> things, not for async logging). While the API isn’t stable, we can abstract
> it well enough with multi version jars. What I’m more curious about is how
> we’d interact (if at all) with virtual threads, coroutines, or structured
> concurrency APIs in general. If an app uses structured concurrency
> throughout, it might want the logging system to participate in the same
> flow for clean shutdowns.
>
> Does anyone have any more concrete use cases that might be relevant for
> us? Or does this seem more relevant for networking libraries and frameworks?
>
> —
> Matt Sicker