Affects: 2.1.8-RELEASE

Hey

I've set up a ThreadPoolTaskExecutor to be able to stream a big bunch of images asynchronously. While only testing the endpoint returning a ResponseEntity, I decided to just stream up some bytes from a string: StreamingResponseBody body = outputStream -> { outputStream.write("Test".getBytes()); };

However, the outputStream.write fails with an exception that the outputStream is already closed: java.io.IOException: Stream already closed

The OutputStream implementation is CompressingServletOutputStream

This code snippet is only executed once, and using a debugger I can indeed see that the OutputStream has "closed = true" as soon as it is created.

I have a feeling this has to be a bug in some functionality - I just can't see where, or what causes the stream to close.

Comment From: sbrannen

Please provide a minimal example that demonstrates the behavior that you are experiencing (ideally a ZIP file for a project or a link to a GitHub repository so that we can download and execute the application / test case).

Comment From: sbrannen

In addition, have you noticed the following information documented in the Caveats and Notes section of the Ziplet filter README?

Note that if this filter decides that it should try to compress the response, it will close the response (whether or not it ends up compressing the response). No more can be written to the response after this filter has been applied; this should never be necessary anyway. Put this filter ahead of any filters that might try to write to the response, since presumably you want this content compressed too anyway.

Comment From: Peldan

I'm working on producing a minimal example.

In addition, have you noticed the following information documented in the Caveats and Notes section of the Ziplet filter README?

Yes, but I can't really see how that applies here, but I might be a little confused by the terminology. So the issue is that as soon as the OutputStream has been created, it is closed. Even before I have written anything to it. Simply placing a "log.info()" printing the OutputStream, and using a debugger, I can see that it is closed.

This note covers the response, but it says nothing about closing the actual stream. Also, how would it decide to compress before I have written to it?

EDIT:

Odd. Creating a new minimal project for an example, with the exact same spring versions, resulted in the OutputStream being a CoyoteOutputStream and the issue was not there.

^ I just found that, indeed, this ziplet package is on the classpath and used as FilterRegistrationBean. Perhaps that is where I should look.

Comment From: Peldan

Okay. The CompressingFilter from ziplet was used. Removing it resulted in another OutputStream implementation, and the problem was solved.

So this probably wasn't a Spring bug then, but I still don't understand why the stream would just close.

Comment From: sbrannen

Okay. The CompressingFilter from ziplet was used. Removing it resulted in another OutputStream implementation, and the problem was solved.

Great! Thanks for letting us know.

So this probably wasn't a Spring bug then, but I still don't understand why the stream would just close.

You'd have to look into the documentation and configuration options for the Ziplet filter to figure that out.