I see additional use cases like sending an email async with the contents of some Sling rendering.
So basically we have two different use cases here: a) functionality like "nohup &" combination in *nix shells b) request processing which is not triggered by an external http request. Usually this is triggered by events or scheduled While we could solve a) like Felix suggests, b) needs something different. Carsten Victor Saar wrote > Hi, > > I'm currently working on something that could highly benefit from > Bertrands approach of exposing the SlingMainServlet, so I just > throw in my use case for (hopefully) consideration: > > What I'm trying to do right now is to render selected parts of the content > in a certain representation, which is identified by an extension and > selectors. The result is then packed in a zip file and stored in the > repository > for later delivery. The update of the zip file is triggered by some event > (e.g. > a change to the repository or configuration) and is thus outside of the > usual > request/response cycle. > > Since the update could be very expensive, rendering the content when > the zip file is requested (using the request dispatcher) is not really an > option. > > I'm not aware of any other method to render a resource outside of the usual > request/response cycle, so using the SlingMainServlet through the exposed > interface looks like the only option. > > Regards, > Victor. > > On Mon, Jul 19, 2010 at 8:08 PM, Felix Meschberger <[email protected]>wrote: > >> 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 >>> >> > > > -- Carsten Ziegeler [email protected]
