The maximum count and maximum size of the cache can now be
specified and a storage can declare what capabilities it has.
If a storage modile cannot enforce the maximum count or maximum
size limits, the storage is decorated with an LRU storage that
can.
The LRUStorage hierarchy implements the decorator pattern and
is capable of providing LRU behaviour to any underlying storage.
There are two concrete classes - LRUStorageST and LRUStorageMT -
that can be used in single thread and multiple thread contentx,
respectively.
Also tests the convention of placing _ as suffix on member
variables.
The query throttling functionality was broken by the move to the per
thread rule system. One way to fix this is to move the session specific
throttling information into the client session itself. This allows for a
simpler system with no direct dependencies on the rules or users
themselves.
The modulecmd functionality allows the avrorouter to easily control the
conversion process with one command. The conversion can now be started and
stopped by the user.
This also fixes a bug where the conversion would stop if there were no
binlog files present when the service was started.
MXS-1009. This commit adds a gwbuf_free after maxinfo_execute() to
free a buffer with an sql-query after it has been processed. Also,
the parse tree in maxinfo_execute_query() is now freed. The tree_free-
function was renamed to maxinfo_tree_free, since it is now globally
available.
This commit has additional changes (in relation to the 1.4.4 branch)
to remove errors caused by differences in the html and sql-sides of
MaxInfo.
Storage is now abstract with StorageReal (that uses an actual
storage module) derived from it. This to prepare for a stackable
case where LRU behaviour is implemented in front of the actual
physcal storage.
The per thread cache is implemented so that there is one single
thread cache per thread.
This uses shared_ptr, which is available in different places
depending on which GCC version is default on the target platform.
So, before this is merged to develop, that needs to be sorted out.
A simple cache is one that does not transparently use multiple
storages in the background. That will be the case when a separate
cache per thread is used. Both CacheST and CacheMT are now derived
from CacheSimple.
A fair amount of what used to be in Cache has now been moved to
CacheSimple. What remains is what surely is common for all cache
types.
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.
