Enabling it will give a performance improvement and it offloads work from
the CPU. This leads to better and more complete utilization of system
resources.
The server allows both unencrypted and encrypted connections on the same
port. MaxScale only allows either encrypted or unencrypted
connections. The differences as well as the reasoning for this need to be
documented.
The feature was rarely used and was only useful in extremely rare
cases. The functionality can still be emulated, if for some reason needed,
by pointing `logdir` to `/dev/shm` or another tmpfs mount.
- Cannot be supported with std::thread.
- Unlikely that the default size (8MB) would ever be too small and
if it is, there is some problem.
- The stack size can be specified using 'ulimit -s' before starting
MaxScale.
Added documentation about creation and destruction of services as well as
updates to service parameters and relationships. The direct updating of
service relationships for filters is not yet implemented.
Enabling it with a value of 1 should remove the vast majority of
connection related problems that appear in MaxScale. This should filter
out most of the errors caused by transient network problems.
The auto_failover is a more reliable solution and should be used instead. Several
unused parameters were removed, although they can still be defined in the config
file. Updated documentation on the relevant parts.
The process of stopping a service will not prevent new connections from
being created. The documentation needs to be extended so that the meaning
of `accepted` is explicitly and clearly stated.
Relaced router_options with configuration parameters in the createInstance
router entry point. The same needs to be done for the filter API as barely
any filters use the feature.
Some routers (binlogrouter) still support router_options but using it is
deprecated. This had to be done as their use wasn't deprecated in 2.2.
To prepare the router's for the eventual removal of the router_options
parameter, the API option arguments should not be used. The parameters can
be substituted by tokenizing the value of the parameter that is still
stored as a part of the service.
