SXSSF works as designed and manages a small memory footprint when generating large files from a database.  But it only writes data to an output stream once everything has been written to SXSSF. This is problematic when used in web applications:

In our use case (our website allows users to generate Excel from the database), generating the SXSSF on the server takes about 5 minutes. Most clients give up within a minute (or the browser does it automatically), or the proxy times out due to no data being sent. Some users also retry the download request. A new request for download is initiated (while the server is busy generating the SXSSF for a client that already gave up). This can potentially lead to DOS.

To work around this issue, I've implemented a super-streaming version of SXSSF, a `SuperSXSSF`, that relies on `rowWriter` callback to generate row data.

With this approach our service is able to stream the generated Excel directly to the client and, best of all, is terminated in case the user cancels the download request. 

The `SuperSXSSF` prevents both download timeouts and potential DOS, while allowing developers all other XSSF actions (i.e. define styles) that don't take much processing time.

Now what?



Modifications at: https://gitlab.croptrust.org/genesys-pgr/genesys-server/tree/master/src/main/java/org/apache/poi/xssf/streaming

Use case: https://gitlab.croptrust.org/genesys-pgr/genesys-server/blob/master/src/main/java/org/genesys2/server/service/impl/DownloadServiceImpl.java