Support virtual threads

[boaks]

See using virtual threads for multiple client emulation.

[Nick-The-Uncharted]

Remember to do socket.setSoTimeout(xxx) org.eclipse.californium.scandium.DTLSConnector#init, or java.net.DatagramSocket#receive may park forever.

[boaks]

or java.net.DatagramSocket#receive may park forever.

Not clear, what you mean. In my experience, there is no need for that. The thread will either wait for a message or an "interrupt" on shutdown.

For which use-case do you consider a socket timeout to be useful?

[Nick-The-Uncharted]

Remember to do socket.setSoTimeout(xxx) org.eclipse.californium.scandium.DTLSConnector#init, or java.net.DatagramSocket#receive may park forever.

Calling java.net.DatagramSocket#receive in virtual thread would lead to virtualthread unparker scheduled after about Long.MAX_VALUE, which leading to negative time returned by java.util.concurrent.ScheduledThreadPoolExecutor#triggerTime(long)

It may become the head of workQueue (depends on whether it overflows again when compareTo). If that happens, the unparker thread could park forever because getDelay is overflowed again to a very big number so everytime the head is peeked from queue, it will still have a positive delay and won't be executed(see java.util.concurrent.DelayQueue#poll()).

See this jdk issue

[Nick-The-Uncharted]

I tried virtual thread at Augest and succesfully started 60000 (limited by avaiable port of linux) with 7s communication period for 24-hours stress test.

I write down what I do at this issue, please see if that helps.

[boaks]

Not sure, at least java.util.concurrent.ScheduledThreadPoolExecutor#triggerTime(long) isn't used directly.
The intended support is limited to dtls + udp receiver threads and udp sender threads. These thread are only used
to read the data from the socket and do a very early decoding in order to be able to do further processing. These threads are not put in "ThreadPools", at least not with the code of Californium.

The ThreadPool dtls uses for the main work-load can be passed in. So such a ThreadPool don't need to use virtual threads.

Is there a hidden mechanism, which uses a ScheduledThreadPoolExecutor for virtual threads without explicitly doing so?

[Nick-The-Uncharted]

Not sure, at least java.util.concurrent.ScheduledThreadPoolExecutor#triggerTime(long) isn't used directly.

It's used by virtual thread unparker (java.lang.VirtualThread#UNPARKER) implictly.

[boaks]

OK. Then it requires a "large timeout" smaller than Long.MAX_VALUE? Which one did you use?

[Nick-The-Uncharted]

I used something like 60 second，but maybe MAX_VALUE/2 is more general 

…

---Original--- From: "Achim ***@***.***> Date: Tue, Dec 17, 2024 21:47 PM To: ***@***.***>; Cc: "Nick ***@***.******@***.***>; Subject: Re: [eclipse-californium/californium] Support virtual threads (PR#2311) OK. Then it requires a "large timeout" smaller than Long.MAX_VALUE? Which one did you use? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[boaks]

I added the socket timeout.
In my tests I wasn't able to reproduce/verify the defect and this workaround as fix (I run 21.0.5 maybe that has already fixed it).
There is one test SecureTest which fails running on jenkins, when virtual threads are used. But succeeds on the same machine running mvn from cli. Using the socket timeout doesn't change that.

[Nick-The-Uncharted]

I added the socket timeout. In my tests I wasn't able to reproduce/verify the defect and this workaround as fix (I run 21.0.5 maybe that has already fixed it).

It only happens when I start tens of thoudsands of client in very fast pace, and they all have short communication period (7s).

Reproducing that maybe hard but at least setting a timeout won't have any bad effect.