Experiencing an issue with ScheduledExecutorService alongside VT
Yuval Lombard
yuval.l at securithings.com
Mon Jul 22 09:13:28 UTC 2024
Probably an executor, just want to make sure we are aligned :)
On Mon, 22 Jul 2024 at 12:11, Yuval Lombard <yuval.l at securithings.com>
wrote:
> Hi Alan,
>
> Thanks, sorry for the confusion, we also saw this odd release, and got
> read of it, it was just a side note btw, because I realized I did not
> attach how I have created my scheduler, so I elaborated on this as well.
>
> Just to make sure by SPTE what exactly do you mean?
>
> We are running into some difficulties now after upgrading to the latest EA
> based on jdk24 where most of our utilized framework's libs are not
> supporting it yet (Spring, and Spring-Boot)
> So if there is an older available EA build based on jdk23 that may be
> addressing one of the possible issues that may got us into this locking
> state, we will be happy to test it.
> Otherwise it will require some work from our end in order to try to
> package our app
>
>
> On Mon, 22 Jul 2024 at 10:46, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 22/07/2024 07:09, Yuval Lombard wrote:
>>
>> Hi Alan,
>>
>> Thanks for the clarifications!
>> OK regarding the pooling of the VT, now I understand what robert meant
>> about the partial code example.
>>
>> The scheduler is created in this way:
>> ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1)
>> then as the code example shows after it is granted with a permit to
>> execute a task, it delegates it to the VT by starting it this way:
>> Thread.ofVirtual().start(() -> { ... }
>>
>>
>> I read Robert's mail as a comment on the code fragment in your first
>> mail. The finally block in that code fragment releases a permit
>> unconditionally whereas I assume you only want to release if acquired in
>> that thread.
>>
>> My comment is about thread dump you attached. Look at threads #73, #77
>> and #83 as examples. The stack traces suggests a SPTE using virtual threads
>> as worker threads. It's nothing to do with the issue we are discussing
>> here, just a comment that on a something surprising that you might want to
>> look into.
>>
>> I upgrade the jdk to the latest EA and test it again, and get back to you
>> in any case with the relevant thread dumps.
>>
>> Thanks. As I mentioned, I think this is related to preemption when
>> cancelling a timer after Object.wait(millis). We may have to publish a new
>> EA build.
>>
>> -Alan
>>
>
>
> --
>
> Kind regards,
>
> *Yuval Lombard*
>
> *Lead Software Engineer*
>
> +972.50.548.0111
>
> yuval.l at securithings.com
>
> [image: logo_black.png]
>
--
Kind regards,
*Yuval Lombard*
*Lead Software Engineer*
+972.50.548.0111
yuval.l at securithings.com
[image: logo_black.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240722/bc8a5bc0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_black.png
Type: image/png
Size: 99833 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240722/bc8a5bc0/logo_black-0001.png>
More information about the loom-dev
mailing list