Revision 979727 provides the following features:
Any servlet executed by Sling can be started in the background by adding the sling:bg=true parameter to the request. The servlet then gets a "fake" request object, some servlets might not like that.
Background servlets are executed by a simple (and limited) thread pool.
Nodes corresponding to jobs are stored under /var/bg/jobs with a sling:bgJobData mixin and the sling/bg/job resource type. The output of a background servlet is stored in a node named "stream", with the sling/bg/stream resource type, under that node.
Default servlets are provided to render the status and stream nodes, when starting a servlet in the background Sling redirects to the status node, using the same extension as the request.
How to test:
Use the engine bundle from the
SLING-1603 branch .
Install the contrib/extensions/bgservlets bundle.
Start the test servlet in the background using either:
Sling returns the job status page, with a link to the job stream. Refreshing the job stream URL returns the full stream as it progresses, saved on every flush() of the running servlet's OutputStream.
Jobs are listed at /system/console/bgservlets which allows them to be suspended, resumed and stopped.
Use existing thread pool and/or scheduling code from Sling.
Access control: status nodes should be readable by their owner only (+ admin of course).
Replace hardcoded values by configuration properties (see TODO in code).
ExecutionEngine should sort jobs by creation date, descending.
Console should allow for identifying and restarting jobs that were interrupted by a shutdown.