cfml

<@U070SQMD1> Any thoughts on this thread:

<https://dev.lucee.org/t/change-the-output-stream/10956/3>

It's related to the post I had the other day. Trying to figure out a way to get Lucee to redirect the output stream to the FS, instead of writing to a StringBuilder and buffering in memory.

The JSP spec indicates the `PageContext` should have a `pushBody(Writer writer)` method should be implemented that would allow you to change the writer being used, but Lucee does not actually implement in `PageContextImpl`. It has it's own `pushBody()` method, which does not allow arguments and handles managin a `BodyContentStack` object.

I tried using reflection to see if I could override things, but it's protected and the JVM isn't letting me get the `PageContextImpl` writer instance.

Have any thoughts on how I might be able to do this?

<@U06V253M4> Do you have any thoughts on this either?

What I'm trying to do is get the output being generated sent to a file, to avoid OutOfMemory issues when the request ends up generating tons of data.

If I can get it to the FS, I can get Nginx to stream the file to the client.

The reason I'm trying to do this at the output stream level, is because of the way this particular project works would take basically a complete re-write to write the content to disk, which would be really time consuming.

However, if I could redirect the output stream to disk instead of a StringBuilder, I could resolve the issue with a minimal amount of work.

If writing to a file world work, wouldn't cfflush also work?

In my case, I'm generating the content in a background process. When the report is done, I need to serve it up to the user.

So I'm wanting to buffer the content straight to disk. When the background job finishes generating the content, then I can have Nginx stream the content right from disk.

So while `&lt;cfflush /&gt;` does empty the buffer (thus lower memory usage), I'd have to have another background process that would take the streamed content and write it to disk. I'd like to avoid that extra step/overhead if possible.

I've considered implementing a listener on the HTTP response, but that would still send the output stream.

It seems like there are more direct methods in CFML for writing to a file.

That may be what I need to do, but the way this code is written today, is going to cause a pretty major re-write. It uses a ton of different nested custom tags and generates output in a number of different formats.

That's why I was just trying to see if I could just capture the output buffer directly.

We may have to put some caps in place to prevent people from exporting XX of rows as well.

That's going to cause some complaints though.

Just curious, what's the most RAM you've given to a Lucee instance?

Java can handle much more, I've just never had the need, lol

We're going to bump up from 4GBs to 12GBs.  I was just curious if the bump up might inoccur issues with GC with the jump in size.

The G1 GC is made for large heaps and has been the default since Java 8 I think