Experiencing an issue with ScheduledExecutorService alongside VT
Yuval Lombard yuval.l at securithings.com
Sun Jul 21 07:05:44 UTC 2024
Hey team We are experiencing some weird halting issues when scheduling tasks with ScheduledExecutorService and VT. We are observing some near deadlock issues / halting of executors which we are not able to reproduce when using platform threads This is one example of a near deadlock situation, where for some reason virtual threads are starting to execute a task, and not reaching the finally block nor the catch Throwable block to release the acquired semaphore permit, reaching to drained semaphore. Are you familiar with this behavior? I hope we are doing something wrong 😅 Note - The scheduler is running on a platform thread ```ScheduledFuture<?> deviceFutureTask = scheduler.scheduleAtFixedRate(() -> { try { logger.debug("[{}] Trying to acquire permit to schedule task [{}] for device. Number of available permits: [{}]", device, task, semaphore.availablePermits()); if (semaphore.tryAcquire(waitingTimeout, TimeUnit.MILLISECONDS)) { logger.debug("[{}] Acquired permit to schedule [{}] task for device", device, task); Thread.ofVirtual().start(() -> { try { logger.debug("[{}] Scheduling [{}] task for device", device, task); // some I/O intensive work logger.debug("[{}] Finished processing [{}] task for device", device, task); } catch (Exception e) { logger.error("[{}] Failed to process [{}] task for device", device, task, e); } finally { semaphore.release(); } }); } else { logger.error("Timed out while waiting for permit to schedule task [{}] for device [{}]", task, device); } } catch (Throwable t) { logger.error("Failed to execute task [{}] for device [{}]", task, deviceId, t); semaphore.release(); } }, (long) (entropy * schedulingInterval), schedulingInterval, TimeUnit. MILLISECONDS);``` We are -- 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/20240721/f0ff250c/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/20240721/f0ff250c/logo_black-0001.png>
More information about the loom-dev mailing list