The service header in include/maxscale/ contains the public part of the
service API. These functions can be safely used by the modules.
The internal header located in service/core/maxscale/ is used by the core
to initialize MaxScale at startup or to provide other services in a more
controlled way (the config_runtime, for example).
The listeners aren't really destroyed and are only stopped. Further
changes are required so that they won't be started again once they have
been destroyed.
Now the basic structure is in place:
- cachefilter.cc is the MaxScale filter interface.
- Cache is the actual cache class that will also handle LRU issues.
- SessionCache (sessioncache.cc) is the session specific cache class
that using Cache acts as the cache for a particular session.
If an item is stale, then one SessionCache will update it.
- StorageFactory is the component that is capable of loading a module
providing storage facilities.
- Storage is the actual key/value store.
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.
