Hi,
> Does this clarify things?
Yes, thanks alot.
And, in fact, it makes me wonder, whether we would not want to allow for
detached request execution in the first place: The SlingMainServlet
allows for asynchronous request execution given some request parameter
(or header or maybe even a selector).
In the SlingMainServlet.service method, the request parameter is
recognized and if set does the following:
* create new request and response objects:
- copy request attributes and parameters
- have response written to repository
- have headers stored in the repository
* call into the service method again with the
new request/response objects in a separate thread
* immediately return the response indicating the
location of the stored response
* ensure request attributes (resource resolver) and
parameters (mostly file uploads) are cleaned up after
asynchronous execution.
This functionality is much like the "nohup &" combination in *nix shells.
It requires no exposure of internals and works transparently because a
servlet or script needs not be aware of being executed asynchronously.
To prevent DOS attacks with async executions, these may be queued using
the Sling scheduling system (or a simple execution queue in the form of
a LinkedList).
To allow a servlet/script to recognize whether it is executed
synchronously or asynchronously (because it might want to adapt its
output ...), which might set a request attribute indicating the fact.
The drawback is, that we grow the Engine bundle by this functionality,
but I would assume, that this is mostly a single internal package with
something like 3 or 4 classes.
WDYT ?
Regards
Felix
On 19.07.2010 16:35, Bertrand Delacretaz wrote:
> Hi Felix,
>
> On Mon, Jul 19, 2010 at 2:58 PM, Felix Meschberger <[email protected]> wrote:
>> ...At first, I am very reluctant to this addition. One reason is that I
>> don't really think it is a good idea to call servlets for non-request
>> processing....
>
> I probably didn't explain the use case clearly enough: it's not
> calling servlets for non-request processing, it's putting servlets in
> the background when they need too long to complete.
>
> It's similar job control on a unix shell: if a pipeline takes too long
> execute, you can send it to the background, bring it back to the
> foreground to examine its output, send it back to the background, stop
> it, etc.
>
> My use case is as follows:
> 1 Joe Programmer writes a servlet or script that in some takes needs a
> long time to run
>
> 2. If he expects the operation to take a long time, Bob User calls the
> servlet with the "run in background" option (client system might need
> to be clever about suggesting this option when it makes sense, but
> users will learn after the first time that something takes too long to
> execute from a browser).
>
> 3. Sling returns a page indicating that servlet runs in the
> background, with a URL to check its output
>
> 4. Bob can disconnect and reconnect his browser without causing the
> background servlet to stop. The interaction can of course be hidden
> behind client-side javascript.
>
> 5. A console allows Joe or Bob (depending on their rights) to
> visualize, suspend, resume and stop servlets that run as background
> jobs.
>
> The cool thing in this is that Joe does not need to do anything
> special about his servlet, it's just programmed in the usual way. With
> the current code, the only twist is that the servlet must write to its
> output at regular intervals, as that's what allows it to be suspended
> and stopped (see [1]). That's good practice anyway.
>
>> ...If we want to have background processing, we should define proper API
>> for starting background jobs and for providing feedback on job progress,
>> like error status, regular output etc....
>
> The contrib/extensions/bgservlets module that I'm working on will
> provide that for background servlets, in a simple form.
>
> If you need this at a more general level, you could move that module's
> ExecutionEngine [2] and related classes to their own bundle and add
> the missing features.
>
> I don't need that now, so at the moment I'm making the bgservlets
> module self-contained, while allowing to use another ExecutionEngine
> later on if needed.
>
>>
>> ...If you still want to process such jobs through the SlingMainServlet, we
>> should define a proper API providing for providing input (real and
>> meta-parameters [is there a difference anyway ???]) and output. This
>> would be similar to the JSR-223 ScriptEngin interface ...
>
> I don't think it makes sense to run generic background jobs through
> the SlingMainServlet, and my bgservlets module does the opposite: it
> runs Runnable jobs using its internal ExecutionEngine, and these jobs
> happen to call the SlingMainServlet.
>
> Does this clarify things?
>
> -Bertrand
>
