Delay write response to after interceptors execution

[nykolaslima]

The issue is related here #1035
(partially fixed by #1036)

We couldn't use HttpServletResponse.reset because if the response being write exceed the buffer size, the content will be automatically flushed.

The idea is to delay the write to response buffer until all interceptors are executed.

@Turini @csokol @lucascs

[nykolaslima]

@Turini @lucascs @csokol I was thinking if we really need to delay the write or if reset will resolve it.

Looks like we can set the buffer size, so we can set it to a "nice value" to avoid buffer to overflow and let this configuration "pluggable" in order to resolve corner cases when applications have huge response bodies.

What do you think?

[lucascs]

Not all streams can be reset. If you already wrote some response to the user, there is no coming back.

If you already launched a rocket, it's done.

[nykolaslima]

But if vraptor wont force the flush, the web server will be the only one to flush it. (Of course if the programmer dont force it, but he shouldnt do that)
So the rocket will only be launched by the web server, wont it? @lucascs

[lucascs]

There is no real guarantee... If we write some big json, for example, part of it might be flushed before the interceptor has a chance to reset it and send a 500 error

[nykolaslima]

Yeah, I agree with you. But I think that generally, the payloads are not higher than a certain amount. Is unusual to have a huge payload, so if we define a "magic size" to the buffer, it will handle 90% of the cases.

But I agree with you, there will be no guarantee because we will always have people returning some unusual payload.

Let's move to the delayed write approach :)