The JSON API specification suggests that the API returns the 403 Forbidden
error when the user does an invalid request. The 400 Bad Request isn't the
ideal error for cases where the syntax is correct but the action being
performed is wrong.
The creation and modification of moitor now supports the JSON API
conforming format generated by the GET endpoints.
Also added tests for creating and altering monitors via the REST API.
The tests now automatically start MaxScale before each test block and stop
it and perform cleanup after the test. This is done by simply calling the
`before.sh` and `after.sh` scripts before each test block.
The `test_rest_api` make target creates a discardable installation of
MaxScale which is used to launch a local instance of MaxScale. This local
instance is then used to test the REST API.
This is definitely not an efficient way to test the MaxScale but it allows
local testing without virtual machines or containers.
Using the JSON Pointer syntax specified in RFC 6901
(https://tools.ietf.org/html/rfc6901) allows for a convenient way to
access values deep in a JSON object.
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.
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.
