The cleanest way to do this would be to somehow force faster recycling of client-side connection pools. This would retain the static nature of the session level configuration and it would remove the need for checks for new servers at all points.

A somewhat crude and brute-force way of doing this would be to introduce a "restart" command for the session. This could be implemented by first calling the close() method of the Session's downstrem Endpoint followed by a connect() call. This would recreate the router and filter sessions which would effectively reload the configuration for active sessions. This is not ideal as it causes the TCP connections to be recycled but it should preserve the session state as that is now stored in the client protocol which is tied to the client DCB.

Added the maxctrl reload session <id> and maxctrl reload sessions commands that can be used to restart the session internally, taking a newer configuration into use. This allows a new set of servers to be taken into use by long-running client connections.

The way the commands were implemented was to open a second internal session before closing the first one in order to minimize the amount of problems this command could create. Given that these commands also reload other configurations than just the servers, this can be used to add filters or change the router configuration of an open session. This also means that the behavior could change in a way that the client application is not expecting: if extreme changes are done to the service configuration (e.g. the router type is changed, extra filters are added or removed), the semantics of the connection can also change. MaxScale tries to prevent this by doing the change only when the connection is idle but the administrator doing the changes must be aware of whether the old session is compatible with the new configuration. For example, removing causal_reads from a readwritesplit service makes it so that reads are no longer synchronized and some applications might not work with this.