Hi,
ok, I see...
In this case, we might want to do the following in the engine:
* create Sling request processor which implements the new
interface as the current SlingMainServlet does
* the SlingMainServlet is modified to also use the Sling
request processor based on an actual request to be handled
* other users will also just use the Sling request processor
and use the request/response builders to provide the
arguments.
It is essential to me, that we properly identify the functionality of
the processor and implement that functionality in the processor. And
that we identify the functionality of the main SlingMainServlet handling
regular requests and implement that functionality in a separate class.
This way, we may clean up the SlingMainServlet and make it smaller and
easier to maintain.
Right ?
Regards
Felix
On 20.07.2010 11:37, Bertrand Delacretaz wrote:
> 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
>
