search

OpenNTF / org.openntf.xsp.jakartaee

XPages Jakarta EE support libraries
Apache License 2.0
21 stars 5 forks source link

Investigate Jakarta Batch #369

Open jesse-gallagher opened 1 year ago

jesse-gallagher commented 1 year ago

https://jakarta.ee/specifications/batch/2.0/jakarta-batch-spec-2.0.html https://blog.payara.fish/enterprise-batch-processing-with-jakarta-batch-1

The Batch API is a bit "enterprise"-y, but may be useful for some work that agents would otherwise do. With the Concurrency API handling keeping modules alive, it may be possible to piggyback on that to keep a batch processor active for defined jobs.

DanieleVistalli commented 1 year ago

@jesse-gallagher this is interesting but... are you thinking to have concurrency API running tasks inside the HTTP/XPages JVM ? I mean.. you look into having a thread pool manager inside that JVM ? What about an extra add-in doing this kind of batch work ? Does this make sense (of course it adds complexity).

jesse-gallagher commented 1 year ago

That's the sort of thing I've wondered about as well. This project already has ManagedExecutorService and ManagedScheduledExecutorService implemented inside the NSF webapp, and so it'd make sense to piggyback any batch processing on top of that. The nice advantage there is that they're more-or-less guaranteed to expire at the same time as the app itself and be nicely contained that way.

On the other hand, both for that already and especially any officially-written Batch jobs, it'd be very useful to have a server-level coordinator, if only to view what's going on. Ideally, there'd be something like the scheduled agents list in Administrator, so you could get an overview of what's scheduled to run and when.