Ruby app with non-system Ruby

[Valentin V. Bartenev]

On Tuesday 29 January 2019 16:07:55 megatux at gmail.com wrote:
> I see. That should work, thanks.
> Now, doesn't this compile-time list of available runtimes limit the
> "dynamic" nature of the service?
> e.g. I'm thinking in the common scenario of upgrading one of the runtimes
> because of a security update.
> This involves starting a new process and move all of its apps & listeners,
> right?
> 
[..]

Unit has much more advanced architecture then most application servers.

Unit contains an asynchronous router process, that deals with connections
and doesn't deal with laguages.  In order to run an application, another
process is forked.  Only after the fork, it loads a required application
module in this new process.  This application process then starts
communication with the router process to serve requests and responses.
So, the modules are loaded only inside the application processes that
don't deal with client connections.

When you have to update your application module because of security issue,
you don't need to restart the whole Unit.

This allows to handle this scenario gracefully with restarting only
application processes without touching listening sockets and connections.

Currently Unit scans modules directory only once in order to know
what languages and versions are available.  In future, it will be able
to rescan this directory, and that will allow not only updating of
existing modules, but also adding new languages and versions dynamically.

  wbr, Valentin V. Bartenev