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 > > > -- Victor Saar Developer mailto:[email protected] T +41 61 226 98 98 F +41 61 226 98 97 Info-World 2009 Technology of the Year Award: Best Web CMS http://www.infoworld.com/slideshow/2009/01/194-2009_technology-4.html Day Software AG Barfüsserplatz 6 CH-4051 Basel http://www.day.com twitter: @daysoftware ************************************************************************ This message is a private communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. The sender does not assume any liability for timely, trouble-free, complete, virus free, secure, error free or uninterrupted arrival of this e-mail. For verification please request a hard copy version.
