Re: Continuous Deployment of Boost.Beast-based server

From: Martijn Otto (boost_at_[hidden])
Date: 2020-04-21 18:16:47

On Tue, 2020-04-21 at 18:59 +0200, Dominique Devienne via Boost-users
wrote:
> On Tue, Apr 21, 2020 at 2:40 PM Martijn Otto via Boost-users <
> boost-users_at_[hidden]> wrote:
> 
> > The easiest way is to simply replace the old process with the new,
> > improved version after stopping the listener for the old process.
> > 
> > The io_context is kept alive by handlers registered. Initially,
> > this is
> > probably only the acceptor listening for incoming connections.
> > Then, as
> > connections are established, handlers are registered for those too.
> > When you want to replace the process, you cancel the acceptor, so
> > only
> > the existing connections keep the io_context alive.
> > 
> > At this point, the listener is closed and the port is free to use
> > by
> > the new process. When all connections in the old process terminate,
> > the
> > process then stops (because no more handlers are registered).
> > 
> 
> That's interesting, and simple. I guess I could extend one of my HTTP
> route,
> or my existing WebSocket protocol handling, to have the new server
> communicate
> with the old one, notifying him to drop the listener, and stop
> listening on
> the main
> port, so that the io_context naturally can go out of scope, and the
> process
> terminate.
> With possibly a grace period for existing clients to disconnect
> normally,
> before forceful termination.
> 
> 
> > There is a small timeframe during which requests might fail,
> > because
> > the old process stops listening and the new process is not yet
> > accepting connections. Depending on your platform, there are ways
> > around this (e.g. SO_REUSEPORT on linux).
> > 
> 
> You mean because the main server port would not be released right
> away
> when the older server stops the io_context's TCP acceptor? Preventing
> the
> new server to start listening on that port right away? --DD

It's inherently not synchronized. You have to wait for the old process
to release the port, at which point incoming requests aren't being
handled. Then you have to set up your new acceptor.

As said, there are platform-specific ways around this. I already
mentioned SO_REUSEPORT. UNIX also allows for sharing file descriptors
over unix-domain-sockets. Windows most likely has similar options.

> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users