hello jörg. we had a short discussion about this on our sling hackathon today:
1. check the configured response buffer size of the jetty engine that is currently configured for your instance. if the response you expected is smaller than the buffer size (in recent version this is 24KB i think), error handling should work fine. 2. if your response is smaller than this and it is still happening it is possible that here are calls to response.flush() that should not be done. the recent sling modules should be correct and not using response.flush() during rendering, but check your environment if this is the case there as well. 3. additionally make sure the JSP files of your application or that are used from the platform do not contain calls to response.flush()! stefan >-----Original Message----- >From: Jörg Hoh <[email protected]> >Sent: Friday, September 7, 2018 7:19 PM >To: [email protected] >Subject: [Discussion] |<sling:include> should buffer output in memory > >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
