On Mon, 2007-08-13 at 12:05 -0700, mccurdyc wrote: > 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.
You're right for ExtensionsFilter, don't know about Ajax4JSF. > > 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? You say "CSV component". Do you mean a JSF component, or just some servlet code? If the CSV export is being done from a servlet (not a JSF page) then there shouldn't be a problem. The url arriving at the server will not be one that is mapped to the ExtensionsFilter and so it won't apply. Maybe you're receiving a JSF postback, then doing an *internal forward* to the CSV generator which is then creating the content? In that case, maybe the output still gets caught by the extensions filter mapping. Using a *redirect* rather than a *forward* should fix that problem. If you really have a csv-generating JSF component then things would be trickier... For more info: http://myfaces.apache.org/tomahawk/extensionsFilter.html Sorry, can't help for Ajax4JSF. Cheers, Simon
