Hi, On Mon, Jul 19, 2010 at 8:08 PM, Felix Meschberger <[email protected]> wrote: > ...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)....
We might also solve that by just adding a "detached request/response" factory service to the Sling engine: give it a request/response pair, and it returns another pair that's suitable for detached execution by the SlingServlet service. The factory could also take other input for easier programmatic use: give it a path, a Map of parameters, and it returns a request/response pair for detached execution. I would just add this to the engine, to avoid bloat, and handle any scheduling/parameter-based detached execution external to that, as I don't think those are core features. > > 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 is pretty much what the current BackgroundServletStarterFilter and related classes do, under contrib/extensions/bgservlets. Or will do soon, I'm still working on it. > > 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... Right - I think the "detached requests factory" would also avoid exposing internals, and maybe modularize things better? > > 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). Agreed > > 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. > Yes, I'm planning to introduce a request attribute that might also provide a facade to the background execution service, for finer status reporting for example. > 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.... If we include scheduling of background jobs, and the ability for jobs to survive a system restart, things get a bit more complicated, so I'd prefer minimal changes to the engine bundle, while not exposing any internals. -Bertrand
