On Wednesday, 31 May 2017 at 13:34:25 UTC, Steven Schveighoffer
wrote:
On 5/31/17 9:21 AM, H. S. Teoh via Digitalmars-d wrote:
On Wed, May 31, 2017 at 09:04:52AM -0400, Steven Schveighoffer
via Digitalmars-d wrote:
I have discovered an annoyance in using vibe.d instead of
another web
framework. Simple errors in indexing crash the entire
application.
For example:
int[3] arr;
arr[3] = 5;
Compare this to, let's say, a malformed unicode string
(exception),
malformed JSON data (exception), file not found (exception),
etc.
Technically this is a programming error, and a bug. But
memory hasn't
actually been corrupted. The system properly stopped me from
corrupting memory. But my reward is that even though this
fiber threw
an Error, and I get an error message in the log showing me
the bug,
the web server itself is now out of commission. No other
pages can be
served. This is like the equivalent of having a guard rail on
a road
not only stop you from going off the cliff but proactively
disable
your car afterwards to prevent you from more harm.
[...]
Isn't it customary to have the webserver launched by a script
that
restarts it whenever it crashes (after logging a message in an
emergency
logfile)? Not an ideal solution, I know, but at least it
minimizes
downtime.
Yes, I can likely do this. This kills any existing connections
being handled though, and is far far from ideal. It's also a
hard crash, any operations such as writing DB data are killed
mid-stream.
..
-Steve
Hi Steve.
Had similar problems early on. We used supervisord to
automatically keep a pool of vibed applications running and put
nginx in front as a load balancer. User session info stored in
redis. And a separate process for data communicating with web
server over nanomsg. Zeromq is more mature but I found sometimes
socket could get into an inconsistent state if servers crashed
midway, and nanomsg doesn't have this problem. So data update
either succeeds or fails but no corruption if Web server crashes.
Maybe better ways but it seems to be okay for us.
Laeeth
