First step in the introduction of a MainWorker. When finished, all
routing workers will run in separate threads (currently one runs in
the main thread), and the main worker run in the main thread.
Housekeeper will disappear and to the extent housekeeping tasks are
needed (where applicable they will be changed into delayed calls)
they will be run by the main worker.
Removed skygw_utils and relate files along with the old log manager
code. Also removed file flushing due to it being redundant; messages are
written to the file immediately. Adjusted tests to accommodate this
change.
The log manager now uses the logger type for logging. Removed some of the
code that depended on the renamed functions to make it compile. The next
step is to remove all unused code in the log manager.
The custom random number generator can now be replaced with a C++11
RNG. This greatly improves the reliability and trustworthiness of it.
In addition to this, the conversion of the RNG to a thread-local object
removes the race condition that was present in the previous
implementation. It also theoretically improves performance by a tiny bit.
The only way to cleanly separate the maxutils library from the MaxScale
CMake project is to make it a standalone CMake project. With the help of
ExternalProject, it should be relatively easy to use.
MaxScale now defines events for which the syslog
facility and level can explicitly be defined by the
administrator. Currently there is only one such
event, namelt AUTHENTICATION_FAILURE.
In a subsequent commit, config.cc will be modified so
that event-related configuration parameters are passed
to event::configure() and in another subsequent commit
the authenticators will be modifed to use this mechanism.
In practice a line like:
MXS_WARNING("%s: login attempt for user '%s'@[%s]:%s, "
"authentication failed.",
dcb->service->name, client_data->user,
dcb->remote, dcb->path);
will be changed to
MXS_LOG_EVENT(event::AUTHENTICATION_FAILURE,
"%s: login attempt for user '%s'@[%s]:%s, "
"authentication failed.",
dcb->service->name, client_data->user,
dcb->remote, dcb->path);
From 10.1.32, 10.2.14 and 10.3.6 onwards, there is an
information_schema plugin called DISKS using which information
about the disk space situation on the server can be obtained.
Subsequent commits will add configuration options for specifying
limits and take the functionality in use in monitors where it makes
sense.
Worker is now the base class of all workers. It has a message
queue and can be run in a thread of its own, or in the calling
thread. Worker can not be used as such, but a concrete worker
class must be derived from it. Currently there is only one
concrete class RoutingWorker.
There is some overlapping in functionality between Worker and
RoutingWorker, as there is e.g. a need for broadcasting a
message to all routing workers, but not to other workers.
Currently other workers can not be created as the array for
holding the pointers to the workers is exactly as large as
there will be RoutingWorkers. That will be changed so that
the maximum number of threads is hardwired to some ridiculous
value such as 128. That's the first step in the path towards
a situation where the number of worker threads can be changed
at runtime.
A new class mxs::Worker will be introduced and mxs::RoutingWorker
will be inherited from that. mxs::Worker will basically only be a
thread with a message-loop.
Once available, all current non-worker threads (but the one
implicitly created by microhttpd) can be creating by inheriting
from that; in practice that means the housekeeping thread, all
monitor threads and possibly the logging thread.
The benefit of this arrangement is that there then will be a general
mechanism for cross thread communication without having to use any
shared data structures.
This is the first step in providing a QueryClassifier class
that is capable of performing context dependent query classification,
where the context is essentially the session state.
According to customer reports collecting the statistics has a significant
impact on the performance. As we don't need that information we can just
as well turn off that.
Further, since maxscale-common now links to the sqlite3-library, no
module needs to do that explicitly.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.
Using the same implementation of the Backend and SessionCommand classes in
both schemarouter and readwritesplit will prevent duplication of code.
This commit only splits the generic parts of the class to a Backend class
which the schemarouter then extends. The session commands for both routers
are similar so they require no special handling.
This allows MaxScale to use the PATCH functionality that's only in the
newer versions of the library. It also removes some of the problems that
exist with older systems that don't support all of the options.
The JSON objects that are created from the various core MaxScale objects
share a lot of common code. Moving this into a separate files removes the
redundant code.
The HTTP side of the REST API is better handled with an actual
library. The libmicrohttpd library provides a convenient way of handling
the HTTP traffic between the clients and MaxScale.
The Resource class is intended to be an abstraction of a resource
tree. Each node in the tree can perform actions. The tree is traversed
depth first so that deeper command paths resolve to the correct nodes.
Currently all the base resources defined in the REST API documents are
implemented in a way that they return a 200 OK response to all
requests. When the internal data can be represented as JSON, the resources
can be hooked up to functions that generate JSON.
The HTTP response class simplifies the response creation. The next step is
to add generation of all the default headers that are needed by the REST
API.
The HTTP request body is expected to be a valid JSON object. All other
requests are considered malformed requests and result in a HTTP 400 error.
Added the Jansson license to the LICENSE-THIRDPARTY.TXT file. Imported
some of the tests from the Jansson test suite to the HttpParser test.
The HttpParser class was renamed to HttpRequest as it parses and processes
only HTTP requests. A second class that creates a HTTP response needs to
be created to handle the response generation.
Moved some of the HTTP constants and helper functions to a separate
http.hh header.
The HTTP parser parses HTTP/1.1 messages into easily manageable data
structures. This should make it easier to map the HTTP requests into
actual commands in MaxScale.
When MaxScale is started, a separate thread for the administrative
interface is started. This allows the worker threads to handle client
requests while the administrative thread handles the lower priority
administrative requests.
The administrative interface responds to all request with a 200 OK HTTP
response. This allows the administrative interface itself to be tested.
A Worker::Task is an object that can be sent to a worker for
execution. The task is sent to the worker using the messaging
mechanism where the `execute` function of the task will be
called in the thread context of the worker.
There are two kinds of tasks; regular tasks and disposable tasks.
The former are just sent to the worker for execution while the
latter are sent and subsequently disposed of, once the task has
been executed.
A disposable task can be sent to either one worker or to all
workers. In the latter case, the task will be deleted once it
has been executed by all workers.
A semaphore can be associated with a regular task. Once the task
has been executed by the worker, the semaphore will automatically
be posted. That way, it is trivial to send a task for execution
to a worker and wait until the task has been executed. For instance:
Semaphore sem;
MyTask task;
pWorker->execute(&task, &sem);
sem.wait();
const MyResult& result = task.result();
The low level mechanism for posting and broadcasting messages will
be removed.
