New candidate JEP: 425: Virtual Threads (Preview)

[Moataz Abdelnasser]

> If you have a long-running CPU-intensive task available from a request, you may have DDos attak problems whatever the kind of threads you use because in both case you will exhaust the pool of available threads to serve the requests.

> Furthermore I’d argue, based on my own experiments, that virtual threads are safer against such attacks. Imagine a thread pool with 1000 platform threads trying to execute 1000 infinite loops. The server would become completely unresponsive and would probably require a hard reset. But the same experiment with 1000 virtual threads would spin a maximum of # of hardware threads. The server would be busy, but not unresponsive.

Good points. I realize virtual threads make throughput their primary
focus, not necessarily responsiveness.

> This question was already asked on this list so i'm parroting
> "Not in the first release, maybe in the future, will see."

Good to know that's at least considered a possibility :)
For fun, I just learned that Go apparently got a non-cooperative,
preemptive scheduler (only) about 10 years after its initial
appearance (https://go.googlesource.com/proposal/+/master/design/24543-non-cooperative-preemption.md).

Thanks & best regards,
Moataz


On Sat, Apr 9, 2022 at 1:11 PM Dr Heinz M. Kabutz
<heinz at javaspecialists.eu> wrote:
>
>
>
> On Sat, 09 Apr 2022 at 12:34, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> ----- Original Message -----
>> > From: "Moataz Abdelnasser" <moataz.nasser20 at gmail.com>
>> > To: "loom-dev" <loom-dev at openjdk.java.net>
>> > Sent: Saturday, April 9, 2022 7:24:45 AM
>> > Subject: Re: New candidate JEP: 425: Virtual Threads (Preview)
>>
>> >
>> > Also, doesn't this make it somewhat dangerous to run a CPU-bound task
>> > in an Executors.newThreadPerTaskExecutor()? I can imagine a DoS attack
>> > where a malicious client makes a server do some long-running
>> > CPU-intensive task in virtual threads enough times that all FJP
>> > parallelism is exhausted. Unlike OS threads, control never goes back
>> > to carriers, denying servicing other clients. If my reasoning is
>> > correct, shouldn't this make it necessary to explicitly caution
>> > against CPU-bound tasks in virtual threads? Perhaps by recommending a
>> > `var result = myFJP.submit(() -> doSomeCpuWork()).get()`.
>>
>> If you have a long-running CPU-intensive task available from a request, you may have DDos attak problems whatever the kind of threads you use because in both case you will exhaust the pool of available threads to serve the requests. And yes, a way to mitigate that issue is to use another pool of worker threads for those tasks and reject the request if this pool has no more threads.
>
>
> Furthermore I’d argue, based on my own experiments, that virtual threads are safer against such attacks. Imagine a thread pool with 1000 platform threads trying to execute 1000 infinite loops. The server would become completely unresponsive and would probably require a hard reset. But the same experiment with 1000 virtual threads would spin a maximum of # of hardware threads. The server would be busy, but not unresponsive.
>
>>
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun/Oracle Java Champion
> JavaOne Rockstar Speaker
> http://www.javaspecialists.eu
> Tel: +30 69 75 595 262
> Skype: kabutz