On Sunday, 1 July 2018 at 20:15:02 UTC, crimaniak wrote:
On Sunday, 1 July 2018 at 13:44:23 UTC, Anton Fediushin wrote:
I reduced the test case to _one_ line:
```
1.seconds.setTimer(() =>
"http://google.com".requestHTTP((scope req) {}, (scope res)
{res.disconnect;}), true);
```
What happens is `res.disconnect` doesn't free all of the
internal buffers, causing leakage. One way to avoid that is to
call `res.dropBody`, but it isn't always wanted (just like in
my example).
The problem is known and mentioned in the documentation:
http://vibed.org/api/vibe.http.client/requestHTTP
Note that it is highly recommended to use one of the overloads
that take a responder callback, as they can avoid some memory
allocations and are safe against accidentally leaving stale
response objects (objects whose response body wasn't fully
read). For the returning overloads of the function it is
recommended to put a scope(exit) right after the call in which
HTTPClientResponse.dropBody is called to avoid this.
As I understand the situation, request object will reside in
memory until you fully read or do something with response body.
It says so "for the returning overloads". Callback-based ones
should be "safe against accidentally leaving stale response
objects". Actually, in this example I don't 'accidentally' leave
objects, I do that on purpose and call `res.disconnect` to
forcefully close everything. Yet it still doesn't free memory.
There's nothing much to do with the response body - it can be
either read and destroyed or just destroyed, and `res.disconect`
should do this.
