vibe.d and my first web service

[ddcovery]

On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
> On Thursday, 20 August 2020 at 18:13:46 UTC, ddcovery wrote:
>> On Monday, 17 August 2020 at 15:45:05 UTC, aberba wrote:
>>> [...]
>>
>> After 18 years following DLang, and some disagrees about 
>> productivity lacks at the beggining (no IDE, Debugging?, an 
>> standard library battle, not a good database connection 
>> library, missing web framework) and Walter adding more and 
>> more compiler functionalities (all of them nice ones) I 
>> decided to forget DLang for a time (C# covered my needs really 
>> well).
>>
>> Last month I decided it was time to start a new project (my 
>> own company) and I reviewed some languages/frameworks for web 
>> development (REST services, image processing, PDF generation, 
>> ...):  Java based ones (I'm experienced with 
>> scala/playframework and spring/java, and Kotlin is really 
>> nice), c# and Net core, Node/Typescript (Last 6 years I have 
>> been mainly a node backend developer) and,  finally, native 
>> ones (GO, Rust and D... I developed some windows apps in 90's 
>> using Symantec C++ but 20 years are a really long time).
>>
>> I really wanted to give D an opportunity: lets go with vibe.d
>>
>> I tested vibe.d on my ubuntu 20.04 and SURPRISE: the hello 
>> world project began to eat all my machine memory (just 
>> requesting with Firefox and CTRL+F5 pressed continuosly).  
>> Using an HAPROXY between calls and backend memory problems 
>> disappeared.
>>
>> Process doesn't stop properly after CTRL+C... but I decided 
>> not to be so demanding.
>>
>> I discovered hunt-framework (with a fantastic ORM 
>> implementation) and my eyes shinned. I tried an example 
>> project. Like vibe.d, I began to perform requests with Firefox 
>> and CTRL+F5 pressed and application stopped immediately 
>> (yesterday I discovered it is a SIGPIPE unmanaged signal that 
>> stops the process).  I'm quite sure if I use HAPROXY to 
>> intermediate between requests and backend, the problem will 
>> disappear, but I don't want to perform this test, because I 
>> decided not to use hunt-framework neither.
>>
>> Finally I'm using Rust (with Rocket and Diesel):  it's my 
>> money folks :).
>>
>> Sorry for this not constructive post.
>>
>> DLang needs to bright in some market niche to attract 
>> developers and to solve the actual most demanded needs:  a lot 
>> of developers, like me, expect a good/robust framework for 
>> backend development (web/rest/microservices/data processing) 
>> and a de-facto standard library for Database integration.
>>
>> In my opinion, "hunt-framework" (or similar) should be one of 
>> the central projects of DLang next years (like vibe.d in the 
>> past) with a really impressive documentation (English, 
>> please!!!) demonstrating how robust, performant and expressive 
>> D lang is.
>
> Actually your feedback is very constructive, thanks a lot. The 
> ctrl+c issue can be solved with a work around, by adding the 
> version "VibeHighEventPriority".
>
> I have only a very small vibed backend application (websockset) 
> and never noticed the memory issue. Also another forum user 
> which has a quite large web application in productive use 
> didn't mentioned this issue.
>
> Could I ask you to open a github issue for vibe-d describing 
> your findings regarding the memory issue?
> As far as I remember the GC does not immediately runs, but only 
> at a certain limit. Maybe your memory issue isn't really an 
> issue but the desired behavior. (Not an expert here, just what 
> I remember).
>
> Kind regards
> Andre
Thanks a lot Andre,

I opened immediately the issues to receive some feedback:

In vibe.d
https://github.com/vibe-d/vibe.d/issues/2459

In hunt-framework
https://github.com/huntlabs/hunt-framework/issues/161

With vibe.d case, memory is never recalled.

Problems disappear in vibe.d when I introduce an intermediate 
HAPROXY... this gave me an idea about the origin of the problem:  
Local pipe closed by destination (that haproxy manages nicely)

Linux man page about write and EPIPE: 
https://linux.die.net/man/2/write
> EPIPE
>    fd is connected to a pipe or socket whose reading end is 
> closed. When this happens
>    the writing process will also receive a SIGPIPE signal. 
> (Thus, the write return
>    value is seen only if the program catches, blocks or ignores 
> this signal.)

I have to recognize I learned this last days (I am not a native 
linux developer, but I began to recall my past knowledge about it 
:-)

The main reason I have dropped the 2 frameworks for my new 
project:

* Entry "ready for use" projects simple examples must work (I 
can't be confident that projects based on them will be stable on 
production if basic projects fail in development)