Afternoon, The application I'm working on had a CSV export component developed with all sorts of wizzy-bang business logic and is fairly important to our customer. The problem is while reviewing it yesterday I came to notice that it was taking up a huge amount of memory while generating exports. I reviewed the code, saw that it was streaming reasonably to the response print writer, but while debugging it appeared as though the print writer to never actually being flushed or sent to the client. After adding several flushes and response.flushBuffer() I got baffled. So I debugged in to the bowels of our filters and found the ExtensionsFilter (and Ajax4JSF filter) to be the culprits. It seems that they wrap the response and request object with their own buffers and only flush them when the response is complete. I assume this allows them to easily inject javascript and such. However this storing instead of streaming to the client plays heck with our 100MB CSV file.
The other crux of the matter is that the component was written in a tightly coupled manner with the page and the state it is in. So my first inclination was to write an export servlet that bypassed these filters, but the work involved with decoupling this component and making it in to an export servlet due to time constraints, is likely a last resort. Our more hackish solution is to write or extend new filters and wrappers to replace the ones in ExtensionsFilter (and Ajax4JSF) and expose the real response object there. I dislike hackery, but I'm at a loss for something cleaner. Any ideas, comments, or suggestions? Thanks! Chris JSF 1.1, Tomahawk 1.1.6, Ajax4JSF 1.1.1. -- View this message in context: http://www.nabble.com/ExtensionsFilter-wrapping-response-requests-tf4263055.html#a12132059 Sent from the MyFaces - Users mailing list archive at Nabble.com.
