Hello all! I ran into an issue recently where I ra...

# ktor

[Todd]

Hello all! I ran into an issue recently where I ran out of space on my server due to tons of temporary files. I was able to narrow it down to the fact that I was not calling the dispose() function on my multipart file upload. I was curious if anyone knows why the logic in the dispose function is separate from the close() in the stream? Is it not good to have side effects unrelated to the actual stream in the close()?

[Aleksei Tirman [JB]]

I think because the stream is just an abstraction for the underlying source of data. Engines have different implementations for multipart/form-data parts and each has its own method for releasing resources. For example, when the CIO engine is used the dispose method releases headers and discards all bytes in the body channel. In the Netty engine for file parts, the FileUpload interface is used that has a delete method that deletes the underlying storage for a file item.

[Todd]

Makes sense. I can see the logic behind it. Just feels weird because if I’m done with the inputStream I don’t see why I wouldn’t want to also clear the resources that helped create the stream (although I see your point about releasing the headers). Unless it’s because the code is heavily blocking or something? Either way I’m still a newbie in this field so I’m sure it’ll make more sense in time. Appreciate the explanation!

[Aleksei Tirman [JB]]

I guess that the input stream uses an underlying object for reading bytes. In other words, it's not self-contained (if you close an underlying source then you'll be not able to read from a stream). I agree that having a separate dispose function is kinda weird and it would be more clear to have a closeable (releases all associated resources) object that one can read data from.