In my sling application I have a number of nested components, which are
called via the <sling:include> tag. If a component late in the rendering
process throws an error, I would like to return an HTTP statuscode 500. But
if more data than the size of the output buffer are written, the response
headers are already comitted and written to the network, so I cannot change
the statuscode anymore and I get in the log something like "response
already comitted". Thus the client receives a HTTP status 200, but the
rendering is not complete.

The problem could be mitigated, if the <sling:include> tag could provide a
ByteArrayOutputStream as part of the Response object, so there is never an
overflow of the OutputBuffer. Instead everything is buffered until an
explicit flush is invoked (which is already happening). This would cause
the entire rendering output being stored in-memory while retaining the
ability to set the HTTP statuscode (and less important: all other response
headers) until all the request processing is completed.

This would avoid my problem of sending a statuscode while the rendering is
not completed yet. As downsides:

   - The response cannot be streamed to the client while the rendering is
   still happening, potentially slowing down the response.
   - The memory usage to process a request will increase.

If you need to stream data or send large amounts of data, you could still
implement a servlet and avoid the use of the taglib; but for the usecase
where the sling:include is used, the output is unlikely to grow into the
megabytes.

WDYT? Should this part of sling, or should be rather create a custom tag
library with our own version of the non-streaming "include" tag?

Jörg
-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

Reply via email to