The storage module is abstracted with StorageFactory that is capable
of creating Storage instances. The latter contains the data and
provides the behaviour for using the actual storage implementation,
which sits behing a C API, conveniently.
The created listeners are now stored to disk like created servers
are. This allows them to be used even after a restart.
Currently, the listeners cannot be deleted and need to be manually
removed.
The server test used the wrong name.
MySQL users test loaded multiple modules in one function call and wasn't
appropriate for an internal test suite test as it requires a working
installation.
The cache filter didn't set the library paths before trying to load
modules.
The binlogrouter was missing a NULL check which caused a crash.
Maxadmin now supports the runtime creation of listeners. The new 'default'
value can be used to signal values that don't need to be configured and
the default value should be used.
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.
Added a document that describes the module command system and added the
necessary information in the dbfwfilter documentation.
The release notes also point to the newly created document.
If an item cannot be put to the database, it is explicitly removed
to ensure that we cannot have the situation that a stale item is
continuously returned because the updating of the value fails for
whatever reason.
If a cached entry becomes stale, then if no extra measures are
taken then every thread hitting that item while it is being fetched
from the server will also refresh it, even though it obviously is
sufficient that one does it.
Now the knowledge that the item is being refreshed is recorded,
so that all other clients are simply returned the stale item. That
way, we'll hit the server once per stale item.
The rules and users are stored in thread-local pointers which removes the
need to hold global locks. This allows greater scalability but causes a
slightly larger memory footprint. Usually the increase in memory
consumption is trivial compared to the benefits in scaling.
Using a per-thread rule and user list allows changes to be applied
immediately without locking on the instance level.
The updating of the rules uses the new functinality described in the
debugcmd.h header. The module registers two functions at startup; one for
reloading rules and one for printing them. These custom functions can be
seen in the `maxadmin list functions` output.
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.
When a backslash is encountered, the backslash should not be
copied but only the character after that.
For the sake of completeness, a few more characters would have
to be handled explicitly, but as the content of a string will not
affect the statement's classification there is not much point in
doing that.
MXS-843. When a monitor executes an external script in response to
a server event, the execution is logged to the MaxScale main log.
Previously, the log message only contained the script name as given
in the configuration file. Now, the message contains the script name
and argument values as given to the execvp-call.
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 C and C++ are mixed in a project, main() should be compiled
as C++ to ensure that all C++ static initializations are performed
properly. That may not be strictly true anymore, depending on the
used compiler and environment, but better to do that to be on the
safe side.
Since it's a cache, we do not need to retain the data from one
MaxScale invocation to the next. Consequently, we can turn off
write ahead logging completely if we simply wipe the RocksDB
database at each startup. In addition, the location of the
cache directory can now be specified explicitly, so it can be
placed, for instance, on a RAM disk.
The prepared statements were router according to the real type instead of
being router to the master. This was caused by the change in the route
target function.
