High memory usage in vibe.d application

[Anton Fediushin]

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.