Java streaming rest API

Question

I'm always confused about how to stream a response back to the client, for example a large csv file, and I'd like to ask some questions:

1. I'm reading the file line by line and write directly to the output stream little by little with flush(), is this enough or it still depends on the flush() implementation on the specific OS?
2. Suppose I have a very powerful machine and only flush at the end, can the client still process the answer in a stream way (without loading all the content into the memory)?
3. The client mentioned the response may not be chunked, and it's about Chunked_transfer_encoding, so how does this impact the response? BTW I already know the response size when I send back the file.
4. The client also talked about StreamingResponseBody. What I understand is this is only for asynchronous processing, we can stream data back without using it.
5. Last question, does Reactive programming has anything to do with this? My user case is really simple, no concurrent request involved. I know there are a lot of modern frameworks in all the languages, but I'd prefer understand the basic stuff first.

Sorry about all the questions.

Desmoid

Answer 1

1. you use Java flush(), and it behaves identically on each O/S, even if O/S flush can differ.
2. client sees only a stream of data which does not depend on how it was generated.

...

5. Reactive programming has notthing in common with this. It is used to minimize memory consumption for large number of connections. If you have less than 1000 clients, use plain synchronous multithreading. It is easier to code and debug.

Smalt

Thanks for your answer, this is basically what I think. About the flush() method, I mean when we flush in java, is it guaranteed that the OS will do the flush, because if it's not, then actually it's still possible that data be flushed once to the client. – Desmoid

for details of flush behaviour, read documentation docs.oracle.com/javase/7/docs/api/java/io/… – Smalt

Answer 2

StreamingResponseBody is part of the Spring Boot Framework. If your client has specifically mentioned it, it might be because they're more familiar with Spring Boot clients as it provides a standard abstraction for handling complex processing like stream management. Furthermore, even if your server is powerful enough to load entire large file content into memory - there can be network limitations in sending back such large data in a single chunk - it might cause errors at the client side. So using a streaming mechanism would be advisable

Taintless

Answer 3

This is not actually what you do in practice with large files. What you would normally do is when you receive the request to produce some file foo.txt you can response immediately with a url: https://foobar.com/foowillbehere/foo.txt, (or you could hold the connection but that is not considered good practice for a long process).

In the backend your would write to a location which is the location the url https://foobar.com/foowillbehere/foo.txt resolves to for clients. This can either be a file server/web storage.

Now if they request the file again, you've got it ready to serve. If something goes wrong in a particular step you can simply retry and the client doesn't know if they can still download the file from the url you've given to them etc. Otherwise you'll have a very poor user experience as if anything goes wrong with the connection, they will need to request this large file again, and you also don't have it readily available to serve. The other thing you can find is often if you tie the HTTP connection and the processing together, you app can crash if too many files are being uploaded at the same time. We found this before we moved the upload of our app to s3, and then separated the servers doing the file processing from the servers responding to REST requests.

Magdalenmagdalena

Thank you for your answer, but this is not what I'm asking. The file is ready when user asks for it (user sends a post which will produce the file, but it takes time, so we do it asynchronously, and then user sends a get to download the file). – Desmoid