If the SSL configuration of a server was altered successfully, it would
overwrite an existing configuration leading to a true memory
leak. Converting the SSL_LISTENER structure to a list allows it to store
the old configurations without leaking the memory.
This has no functional benefits apart from storing references which could
aid in debugging. In the future, the discarded configurations could be
freed once all connections that use it are closed.
The config_runtime.h header contains functions that can be used to
manipulate the running configuration. Currently the header contains the
function to create, add, remove and destroy servers.
The packet was generated with the wrong number of elements due to usage of
sizeof on an integer where the correct type was an uint8_t.
This only fixes the malformed packets but does not fix the root cause of
the problem. The affected rows and last insert ID are length encoded
integers which should be handled. The current code treats them as one byte
fields.
To prevent bugs caused by pointers having the wrong type (e.g. uint32_t
instead of uint8_t), some macros are changed into inline functions so that
the normal type-checking is performed.
The macros MYSQL_GET_ERRCODE, MYSQL_GET_STMTOK_NPARAM, MYSQL_GET_STMTOK_NATTR,
and MYSQL_GET_NATTR were not changed, because they may be too specific to
be present in a general purpose header in the first place.
DCBs and SESSIONs can be passed either as raw pointers or as the string
representations of them.
The preferred way to pass them is to use the raw pointer types. This
removes the need to convert the pointer to string form and back.
The modulecmd_foreach function allows commands to be iterated without having
to manage the locking of the system. This allows the commands to be easily
iterated and gathered into filtered lists without having to build it into
the module command system itself.
The modules can now return human-readable error messages to the caller of
the function. The internals of the modulecmd system also use this to
return errors to the users.
The error messages can be retrieved with a common error function which
should make it easy to use in various clients.
A module can register a function to a domain. These function can then be
called by external actors enabling the modules to expand their
functionality beyond the module API. Each module should use its own domain
e.g the library name.
Currently, the functions do not return results. The possible next step
would be to alter the function entry point to return a result set of
sorts. This would allow the modules to convey structured information to
the client information which would handle the formatting of the result.
Although this sounds good, it is not required for the implementation of
MXS-929.
When a service is added or removed from a service, a supplementary
configuration file is created. This allows MaxScale to survive restars and
unexpected downtime even if runtime changes to the servers of a service
have been made.
With these changes, it is possible to start MaxScale without any servers,
create servers, add the created servers to services and monitors and
restart Maxscale without losing the runtime configuration changes.
When a server is added to a monitor, an supplementary configuration file
is generated to persist this information. This will allow dynamic
modifications to server lists which will survive restarts and unexpected
downtime.
The monitor will only add new servers to its list of monitored
servers. This prevents duplicate entries in the list and makes it safe to
persist all used servers to the supplementary configuration file instead of only the ones that are not listed in the main configuration.
Servers created at runtime can now be configured to use SSL. The
configuration is only possible if the server is not in use.
The `alter server` command in maxadmin now takes a list of `key=value`
strings. This allows the user to define multiple alter operations with one
command.
The functions allow simple operations on configuration context
objects. This makes it easier to understand what the code does and allows
reuse of the configuration processing code.
Together with the field names, now qc_get_field_info also returns
field usage information, that is, in what context a field is used.
This allows, for instance, the cache to take action if a a particular
field is selected (SELECT a FROM ...), but not if it is used in a
GROUP BY clause (...GROUP BY a).
This caused a significant modifications of qc_mysqlembedded that
earlier did not walk the parse-tree, but instead looped over of a
list of st_select_lex instances that, the name notwithstanding,
also contain information about other things but SELECTs. The former
approach lost all contextual information, so it was not possible
to know where a particular field was used.
Now the parse tree is walked, which means that the contextual
information is known, and thus the field usage can be updated.
The checks for the server active status are now hidden behind a
macro. This allows for the conditions of the activity to change without
having to alter the code that uses it.
Server creation and allocation are now the same apart from the fact that
allocation only adds the server to the running configuration where as the
creation of a server also persist it to disk.
The server serialization should not be seen through the server.h API. This
allows the serialization method to change without actually having to
change the interfaces.
If a server were to be destroyed, it should not show up among
non-destroyed servers. Even though the servers aren't actually destroyed,
it hides unnecessary information from the user.
When a server is created via MaxAdmin, it will be serialized to disk. This
allows created servers to be retained through a restart of MaxScale.
Currently, all serialized objects are stored in one folder and there is no
structure in the created files. In the future, servers could be created
under a `servers` subdirectory so that it is easier to see what was
added. Whether there is a need for this will be seen.
The persisted configuration subdirectory will be used to store changes to
the configuration. The gwdirs.h header now supports setting and getting
the value for this directory.
The address, port, monuser and monpw parameters of an existing server can
be changed at runtime. The support for enabling SSL will come in a later
commit.
Allowing servers to be modified could also be done by destroying and
recreating them. Since the servers are never actually destroyed, it is
better to allow the alteration of the existing ones.
The `add server` command accepts a server name and either a service name
or a monitor name. It will add servers to services and monitors. Since all
monitors use the MONITOR_SERVER structures directly, the monitors need
to be stopped before new servers are added to them
The function serializes a server to a file. This is intended to be used
with dynamically created servers. The output of the server serialization
will eventually be stored in the configuration file directory (default is
/etc/maxscale.cnf.d/) so that created servers persist even after a
restart.
The BACKEND structure in readconnroute is now replaced with the use of the
SERVER_REF structure of the service. This allows dynamic changes to the
list of servers to be made.
Servers can now be added and removed from services which allows routers to
use them with new sessions. The routers don't fully use the new
functionality in the server references which prevents new servers from
being taken into use.
If shutdown has been initiated (via maxadmin or by sending a
SIGINT or SIGTERM) and a SIGTERM is received, the process
is terminated.
If shutdown has been initiated (via maxadmin or by sending a
SIGINT or SIGTERM) and a SIGINT (Ctrl-C) is received, a warning
is printed that shutdown is in progess. Then, if an additional
SIGINT is received, the process is terminated.
So, in practice:
- If MaxScale is running as a daemon, the first SIGTERM initiates
shutdown and a second one unconditionally terminates the process.
- If MaxScale is running in the console, the first Ctrl-C initiates
shutdown, the second prints a warning and the third terminates
the process.
This is to ensure that MaxScale can be forced to exit, in
case some thread is hung for whatever reason, and is thus preventing
the controlled shutdown.
This allows safer lock-free reads to be done on lists that never shrink in
size. The main use-case for this is to allow servers to be added to a
service without locking the service each time a new session is created.
Synchronizing the memory before adding new components into a list
guarantees that if a session reads from the list and sees the new list
item, the memory pointed by the item is valid.
Function is no longer used and it was quite unoptimal, so now
removed.
qc_get_prepare_name, qc_get_prepare_operation and qc_get_field_info
that were missing from qc_dummy added at the same time.
