One question about the response methods: If I would be using something like `ctx.result(inputStream)` - would it block the [lightweight] thread until all data is written. Or would the handler return and the data transfer happen in the background?
One use-case I've only see marginally addressed in some frameworks is being able to run code past the point where all data is written - e.g. to record logs and metrics around the outcome of a request - e.g. whether the client hung up or all data was stored in socket buffers. If sending the result "blocks", that kind of code can be added naturally with a try/finally block around it.
As far as I understand the docs, it might not block, but one might be able to install an "After" handler? Or would that also only run before the response is actually sent?
If I would be using something like `ctx.result(inputStream)` - would it block the [lightweight] thread until all data is written. Or would the handler return and the data transfer happen in the background?
There is no difference between OS threads and virtual threads in this scenario, and everything in Javalin is blocking (by default).
The `ctx.result()` method doesn't actually write anything directly, it sets a result that will be written later. If you add an "After" handler, this also happens before the request is written. When the request is finally written, it's written on the same thread, and it is a blocking operation.
There is a `RequestLogger` you can hook into that fires after the response has been written.
One question about the response methods: If I would be using something like `ctx.result(inputStream)` - would it block the [lightweight] thread until all data is written. Or would the handler return and the data transfer happen in the background?
One use-case I've only see marginally addressed in some frameworks is being able to run code past the point where all data is written - e.g. to record logs and metrics around the outcome of a request - e.g. whether the client hung up or all data was stored in socket buffers. If sending the result "blocks", that kind of code can be added naturally with a try/finally block around it.
As far as I understand the docs, it might not block, but one might be able to install an "After" handler? Or would that also only run before the response is actually sent?