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 sessions resource now follows the JSON API specification:
http://jsonapi.org/
This makes the API relatively easier to use as the specification and the
client libraries to consume this data exist.
The atomic compare-and-swap can be used to implement lock-free
structures. The planned use for this is to remove some of the locking done
in the services when listeners are being manipulated.
Various small changes to part2, as suggested by comments and otherwise.
Mostly renaming, working logic should not change.
Exception: session id changed to 64bit in the container and associated
functions. Another commit will change it to 64bit in the session itself.
MySQL sessions are added to a hasmap when created, removed when closed.
MYSQL_COM_PROCESS_KILL is now detected, the thread_id is read and the kill
command sent to all worker threads to find the correct session. If found, a
fake hangup even is created for the client dcb.
As is, this function is of little use since the client could just disconnect
itself instead. Later on, additional commands of this nature will be added.
Without the member template it is not possible to pass an auto_ptr
instantiated with a derived type to post() or broadcast().
The reason is that the conversion constructor and conversion
operator of auto_ptr are equally good for that purpose, and hence
the compilation ends with an error.
WorkerDisposableTask is intended to be passed using auto_ptr, to
make it plain that the ownership is moved. If it's inherited from
WorkerTask it can be passed as a WorkerTask, which is confusing as
it in that case will not be disposed of.
The compiler will anyway insert padding to ensure the size of the
structure is a multiple of 8. That will under Valgrind show up as
writes of uninitialized data when the messages are sent over the
pipe.
Rather than forcing the structure to be aligned on 4 byte boundary
we simply expand the id field to an 8 byte type.
The parameters were validated with the correct object names but the actual
parameter values weren't converted to the new system. This caused a crash
when the service parameter validation was successful but the actual
retrieval of that parameter resulted in a NULL pointer.
The filter names for the service parameter `filters` weren't converted
into the new format. This caused a configuration error when a filter with
significant whitespace in its name was used in a service.
The modules, their types and default values are exposed via the
/maxscale/modules resource. Currently, only a list of resources can be
exposed as the externally exposed module object (MXS_MODULE) does not have
the name and type information in it.
When a monitor is created, any parameters given to it are immediately
processed. This is done by processing the initial request as if it were an
update to the monitor that was just created.
Changed the order in which servers are linked to objects. The old
relations are removed first and only after that are the new relations
added. This fixed a problem when the monitor which monitors a server was
being changed.
Also fixed a few minor bugs.
Destroyed servers were still shown as a part of the servers resource
collection.
If a parameter defined in persisted configurations was replaced, the value
would be appended to itself after it was replaced.
Return correct error codes for internal errors.
The server check was checking for old parameter locations.
Service parameters can now be altered with a PUT request to the REST
API. This allows general level parameters to be altered.
Module specific parameters need to be altered with a different mechanism,
namely the module command system. This requires that a generic way to call
a function needs to be devised.
When a persisted configuration file is read, the values in it are
considered to be more up-to-date than the ones in the main configuration
file. This allows all objects to be persisted in a more complete form
making it easier to change configuration values at runtime.
This change is intended to help make runtime alterations to services
possible.
The PATCH method isn't supported in older versions of microhttpd. As this
functionality wasn't used, it can be removed until it is needed. The PUT
method already allows updates by defining complete resources so PATCH is
only an improvement, not a requirement.
The `user`, `password`, `version_string` and `weightby` values should be
allocated as a part of the service structure. This allows them to be
modified at runtime without having to worry about memory allocation
problems.
Although this removes the problem of reallocation, it still does not make
the updating of the strings thread-safe. This can cause invalid values to
be read from the service strings.
If a monitor is started and stopped before the external monitoring thread
has had time to start, a deadlock will occur.
The first thing that the monitoring threads do is read the monitor handle
from the monitor object. This handle is given as the return value of
startMonitor and it is stored in the monitor object. As this can still be
NULL when the monitor thread starts, the threads use locks to prevent
this.
The correct way to prevent this is to pass the handle as the thread
parameter so that no locks are required.
Monitor resources can now be altered with a PUT request. The method allows
alterations on all parameters that the maxadmin `alter monitor` command
allows.
The /sessions/ resource was not implemented due to changes in the core
polling mechanics. With the new worker thread messaging system, sessions
can be listed in a safe manner.
The service, filter and monitor resources now have a "parameters" value
which contains a set of all configuration parameters for that object. This
set contains both standard and non-standard parameters.
Also fixed a mistake in the constant name definitions for the monitor
parameters "events" and "script".
The service resource now exposes the parameters that were given to
it. This allows general service parameters to be changed at runtime
through the REST API.
The alteration function is only called when the value of a parameter
changes. This removes some of the redundant logging that was caused by
calling the alteration function with the same values.
