long running scheduled task #45843
-
|
i would assume that this is a pretty common use case, e.g. sync, housekeeping, reporting and stuff like that. but i couldnt really find a blueprint specifically for that, so i used https://quarkus.io/guides/scheduler. my code looks exactly like that, only that my schedule is something like 'once a day' and my task is not just updating a counter but doing stuff that takes up to 30 minutes. but of course if i do it that way, i get lots of warnings (with full stack traces):
so my question is: am i doing it wrong? and if not, is there a way to suppress the warnings for this task specifically? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 22 replies
-
|
I think you would need an executor to delegate the task to so that you don't block the thread used for scheduler invocations. Another thing is that you can |
Beta Was this translation helpful? Give feedback.
-
|
@mkouba I can understand all the technical reasons why it's not transparent. But I think we can admit it's not an ideal situation from a user point of view. And I agree it should at least be clearly documented as using a scheduler to schedule long tasks is a very common use case. So if we could come up with a solid pattern for that, it's something we would need to add to the documentation. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
It's not ideal but we did not have many users reporting this kind of problem. So it could be that it's not so common, or users simply increase the quarkus.vertx.max-worker-execute-time. That said, it does not hurt to improve our documentation ;-). |
Beta Was this translation helpful? Give feedback.
-
Yeah but that is extremely dangerous as it is global and affecting everything. |
Beta Was this translation helpful? Give feedback.
-
|
"extremely dangerous" in the sense that you don't get the warning, yes. |
Beta Was this translation helpful? Give feedback.
-
|
It may be overkill, but I think it's worth noting that this works ootb with Quartz, as quartz jobs runs on worker threads, so they can run for as long as they wish (keeping in mind threadpool size + possibility of misfire). For scheduled methods, its possible to have them run on quartz worker threads as well (via property). |
Beta Was this translation helpful? Give feedback.
-
|
Hm, yes, but this is only true if |
Beta Was this translation helpful? Give feedback.
-
Should also work if you use Quartz API directly |
Beta Was this translation helpful? Give feedback.
-
|
Of course, but that's not a common/idiomatic way in Quarkus ;-). |
Beta Was this translation helpful? Give feedback.
-
|
I arrived at this too due to unexpected blocked thread warnings when running a long-ish schedule. Maybe thought too simple, but is it worth changing the default to |
Beta Was this translation helpful? Give feedback.
-
|
I'd argue that long running tasks are definitely a valid use case but not necessarily the typical ones for scheduling - at least from what I've seen from issues so far.
That brings some other limitations and possibly unexpected behavior - such as losing duplicated context. Also, how do quartz threads scale? I would assume that offloading all tasks to them can also prove harmful. Personally, I think a dedicated executor for long running tasks makes the most sense although I understand it does require some setup from the user. |
Beta Was this translation helpful? Give feedback.
-
|
Hadn't seen that yet - the way you have it in the docs now seems fine
indeed!
…On Mon, Feb 10, 2025 at 6:01 PM Matej Novotny ***@***.***> wrote:
I'd argue that long running tasks are definitely a valid use case but not
necessarily the typical ones for scheduling - at least from what I've seen
from issues so far.
Maybe thought too simple, but is it worth changing the default to
quarkus.quartz.run-blocking-scheduled-method-on-quartz-thread=true?
That brings some other limitations and possibly unexpected behavior - such
as losing duplicated context.
Also, how do quartz threads scale? I would assume that offloading all
tasks to them can also prove harmful. Personally, I think a dedicated
executor for long running tasks makes the most sense although I understand
it does require some setup from the user.
Note that we have recently added a docs section
<#46100> about long running
tasks so in future users will be able to find at least some guidance.
—
Reply to this email directly, view it on GitHub
<#45843 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6CPHNW223JPSL4BXKV6F32PDLPDAVCNFSM6AAAAABVZKKMG2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJSGM3TAOI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's only in |
Beta Was this translation helpful? Give feedback.
I think you would need an executor to delegate the task to so that you don't block the thread used for scheduler invocations.
You can still use scheduler to trigger the task regularly but offload the task itself to another thread.
From the top of my head, I recall you can
@Inject ExecutorServiceorManagedExecutor. The latter allows for some context propagation but that might end up being more complicated if your tasks are this long.Another thing is that you can
@Inject ScheduledExecutorService- with this you could schedule either a one-off task or even a periodic one so based on what exactly you need, this could replace the scheduler altogether.