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
