Making the lists of persistent DCBs thread specific is both a bug fix and
a performance enhancement. There was a small window where a non-owner
thread could receive events for a DCB. By partitioning the DCBs into
thread specific lists, this is avoided by removing the possibility of DCBs
moving between threads.
When an epoll error occurs for a listener, the errno variable must be
stored in another variable while the listener is removed from all of the
epoll instances.
The `thread.next` pointer refers to active DCBs in the current thread's
list and the `memdata.next` pointer refers to DCBs about to be freed. The
latter was mixed up with the former due to some changes in the naming.
The code prevented scaling by imposing global spinlocks for the DCBs and
SESSIONs. Removing this list means that a thread-local list must be taken
into use to replace it.
The dcb_foreach allows a function to be mapped to all DCBs in
MaxScale. This allows the list of DCBs to be iterated in a safe manner
without having to worry about internal locking of the DCB mechanism.
Each DCB needs to be added to the owning thread's list so that they can be
iterated through. As sessions always have a client DCB, the sessions don't
need to be added to a similar per thread list.
This change fixes a problem with dcb_hangup_foreach that the removal of
the list manager introduced. Now the hangup events are properly injected
for the DCBs that connect to the server in question.
Since the listmanager code isn't used, the debug assertions will always
fail. They should be disabled until the listmanager code can converted to
the per-thread model.
Because each thread has their own epoll file descriptor and only one
thread can process a DCB, it makes sense to move to a per thread zombie
queue. This removes one of the last restrictions on scalability.
The thread-specific spinlock needs to be acquired before a fake event is
inserted from a non-polling thread. The usual situation is when a monitor
thread inserts a hangup event for a DCB.
Other, less common cases are when session timeouts have been enabled and
the DCB needs to be closed. Here it is better to insert a fake hangup
event instead of directly closing the DCB from an external thread.
Having a unique epoll instance for each thread allows a lot of the locking
from poll.c to be removed. The downside to this is that each session can
have only one thread processing events for it which might reduce
performance with very low client counts.
Previously, negative values were allowed for persistpoolmax and
persistmaxtime. Now they cause an error. Also, monitor_interval
allowed negative (or zero) values, which were then implicitly cast to
unsigned, causing unintended behaviour. Now this causes a warning
and the default value is used.
If the user running MaxScale could open the .secrets-file and the
file permissions were anything other than owner:read, the
secrets_readkeys() would fail with error message
"Ignoring secrets file <path>, invalid permissions." Now the
message is more accurate in stating the expected permissions.
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.
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.
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.
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.
The code that checked whether a server was added to a service did not
check whether the server reference was active. This caused problems when
an old server was added again to a service that once had used it.
